On Mon, Apr 20, 2020 at 3:38 PM Segher Boessenkool <seg...@kernel.crashing.org> wrote: > > Hi! > > On Mon, Apr 20, 2020 at 09:56:34AM +0200, Richard Biener wrote: > > On Fri, Apr 17, 2020 at 10:51 PM Segher Boessenkool > > <seg...@kernel.crashing.org> wrote: > > > > 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. > > Yes, I very much agree :-) But how will we do this? Make it warnings > only, and have those opt-in (for a port) even?
Add -fcheck-rtl, when you're ready (per port?) make it default for bootstrap. When you're even more "ready", turn it on with -fchecking (or --enable-checking=xyz). We've gone a similar way with the GIMPLE checking (not SSA checking, that was always present) which was formerly called "type" checking but now verifies more details. It was broken quite badly as well and mostly incrementally fixed (some cases by intentionally weakening the checker). Of course as you say with RTL you have all the targets to consider ... > > > > 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). > > Yeah, that would be much simpler to do as well. > > > 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). > > Probably most, yeah, but some things that expand does should be done > much *later* in RTL even :-) We have combine for that. Eh. > > 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"). > > Expand does a lot of things that are very much historic, too. Sure... Richard. > > Segher
