On Thu, Apr 23, 2020 at 02:25:40PM +0200, Richard Biener wrote: > > > But being stuck with something means no progress... I know > > > very well it's 100 times harder to get rid of something than to > > > add something new ontop. > > > > Well, what progress do you expect to make? After expand that is :-) > > I'd like the RTL pipeline before RA to shrink significantly, no PRE, > no CSE, ...
RTL CSE for example is very much required to get any good code. It needs to CSE stuff that wasn't there before expand. The pass currently does much more (as well as not enough), of course. > The important part before RA is robust and intelligent > instruction selection - part of which is already done at RTL expansion > time. LOL. The expand pass doesn't often make good choices, and it *shouldn't*, it should not make many choices at all; it should just generate valid RTL, new pseudos for everything, and let later RTL passes make faster code from that. > > Most of what is done in RTL is done very well. > > Umm, well... I beg to differ with regard to DF and passes like > postreload-gcse. What is wrong with DF? Is there something particular in postreload-gcse that is bad? To me it always is just one of those passes that doesn't do anything :-) That can and should be cleaned up, sure :-) > > Replacing specific things in RTL, maybe as big as whole passes, already > > is hard to do without regressing (a *lot*). And if there is no real > > reason to do that... > > The motivation is to make GCC faster, obviously. Not spending time > doing things that should have been done before (RTL PRE vs. GIMPLE PRE, etc.). > Using the same infrastructure (what, no loop dependency analysis on RTL?), > etc. But everything you want to remove isn't high on profiles anyway? And you proposed adding bigger, slower, stuff to replace it all with. Slow are RA, and the language frontends (esp. C++ like to take 15% of total :-/) > You could say we should do more on RTL and enhance it instead, like do > vectorization where we actually could have a better idea on costs and > capabilities. But I'm a GIMPLE person and don't know enough of RTL to > enhance it ... Oh no, I think we should do more earlier, and GIMPLE is a fine IR for there. But for low-level, close-to-the-machine stuff, RTL is much better suited. And we *do* want to optimise at that level as well, and much more than just peepholes. Segher
