Jeff Law via Gcc-patches <gcc-patches@gcc.gnu.org> writes: > On Thu, 2020-04-23 at 15:07 +0200, Richard Biener wrote: >> On Thu, Apr 23, 2020 at 2:52 PM Segher Boessenkool >> <seg...@kernel.crashing.org> wrote: >> > 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. >> >> Sure, but then we should fix that! > Exactly. It's purpose largely becomes dealing with the redundancies exposed > by > expansion. ie, address arithmetic and the like. A lot of its path following > code should be throttled back.
Agreed. But things like address legitimisation and ensuring immediate operands are in-range could be done in gimple too, and probably be optimised more effectively and efficiently in SSA form than in RTL. The ultimate question then wouldn't just be "does the target support this optab?" but also "are these operands already legitimate for the optab"? I also wonder how difficult it would be to get recog to recognise gimple :-) Thanks, Richard
