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. > 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 ;-) ) > > > > The web pass belongs immediately after expand; but ideally, even expand > > > > would not reuse pseudos anyway. > > > > > > But for example when lower-subreg decomposes things in a way turning > > > partial defs into full defs new opportunities to split the web arise. > > > > But that is only for the new registers it creates, or what am I missing? > > No idea, just made up the example that maintaing "SSA" RTL is > not automagic. Oh sure, but in most cases, it is. My point is that making web form only once (and messing it up after that) isn't great. > > > > Maybe it would be better as some utility routines, not a pass? > > > > > > Sure, but then when do we apply it? > > > > All of the time! Ideally every pass would leave things in a good shape. > > Usually it is cheapest as well as easiest to do things manually, but for > > some harder cases, such helper routines can be used. > > > > > Ideally scheduling would to > > > register renaming itself and thus not rely on the used pseudos > > > (I'm not sure if it tracks false dependences - I guess it must if it > > > isn't able to rename regs). That would be a much better place > > > for improvements? > > > > sched2 runs after RA, so it has nothing to do with webs? And sched1 > > doesn't do much relevant here (it doesn't move insns much). > > > > I don't see how this is directly related to register renaming either? > > If scheduling ignores "false" dependences (anti dependence with > full defs) then when it schedules across such defs needs to perform > renaming. Maybe I'm using bogus terms here. Your terminology is fine afaic, but I don't see what you mean, sorry. Maybe I don't know sched well enough... I thought it would just refuse to move something if that would result in broken code? Segher
