On Thu, 2020-04-23 at 16:32 +0100, Richard Sandiford wrote: > 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. Yea, but once exposed we'd probably need some kind of way to prevent something like an out-of-range immediate from being propagated back into the statement. Certainly do-able though. Maybe significantly easier than resurrecting RTL-SSA.
> 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 :-) :-) You know better than I... The more structured nature of gimple probably helps that effort. jeff >
