On Fri, Apr 17, 2020 at 10:51 PM Segher Boessenkool <seg...@kernel.crashing.org> wrote: > > On Fri, Apr 17, 2020 at 08:53:08AM +0200, Richard Biener wrote: > > On Thu, Apr 16, 2020 at 7:46 PM Segher Boessenkool > > <seg...@kernel.crashing.org> wrote: > > > > > > On Thu, Apr 16, 2020 at 10:33:45AM +0200, Richard Biener wrote: > > > > On Wed, Apr 15, 2020 at 11:23 PM Segher Boessenkool > > > > > On a general note, we shouldn't depend on some pass that may or may > > > > > not > > > > > clean up the mess we make, when we could just avoid making a mess in > > > > > the > > > > > first place. > > > > > > > > True - but the issue at hand is not trivial given you have to care for > > > > partial defs, uses outside of the loop (or across the backedge), etc. > > > > So there's plenty of things to go "wrong" here. > > > > > > Certainly. But *all* RTL passes before RA should leave things in "web > > > form" (compare to SSA form). The code in web.c is probably just fine; > > > but we shouldn't have one web pass, *all* passes should leave things in > > > a useful form! > > > > Yeah well, but RTL is not in SSA form > > "Webs" are not the *same* as SSA, in a few crucial ways; but they serve > similar purposes: they both make code transformations easier to do. > Both do this by having more different (independent) names. > > > and there's no RTL IL verification > > in place to track degradation. > > Adding this isn't hard in principle. But currently it is violated all > over the place, including in backend code.
It's a cheap excuse and clearly a lot of work. But we've done it for GIMPLE and it was clearly worth it. If only for documentation purposes. > > And we even work in the opposite way > > when expanding to RTL from SSA, coalescing as much as we can ... > > Which often is bad. A lot of what expand does is premature optimisation > that a) is much too complicated, and b) results in worse code in the end. > Expand should not try to do *anything* "interesting", it should "merely" > translate to RTL. > > (And in a way that can be debugged sanely at all, if possible ;-) ) Sure. I've tried to turn off TER with only moderate success. Another approach would be to not do any coalescing but for PHIs (and maybe there only for edges where we cannot insert copies on w/o splitting it). But clearly all the magic expand does now should materialize itself on GIMPLE (see the patch series Martin posted for vcond* / vec_cmp* "expansion" on GIMPLE). It's the magic that requires TER and TER clearly introduces the most noise in the GIMPLE -> RTL translation step (as to code motion and initial instruction selection if it "fails"). Richard.
