Hi, as discussed briefly on IRC yesterday, I would be very happy to see current DU/UD infrastructure changed to FUD chains (or on side SSA form). This way it will be more symmetric to how tree level virtual operands are handled and will hopefully make whole compiler more standard and easier to follow. > > >Thanks for the quick response. As it turns out, the libcall issue will > >soon be gone, as bonzini will be deleting them. We have finally > >overcome that issue. > > Not really. There seems always to be something that prevents them from > being deleted, and I have no time to spend on GCC at work right now. I > believe Steven Bosscher has more detail on that than I do. > > But I don't think that they influence birthpoints, which seems to be > just a way to factor use-def/def-use chains (yes, analogy with the name > of FUD chains is not by chance) without introducing phi functions. phi > operands would be a birthpoint's reaching defs, in practice, right?
Yes, I do believe that wast majority of DU/UD code can stay as it is. We just need to introduce the PHI nodes, either in a way Gimple does that in separate section of CFG or as real RTL noop moves (or we can even have RTL PHI code that would behave same way as USEs does not, ie bypass machine validation issues). We can change the DU/UD representation to allow only one DEF except for the PHI nodes where multiple DEFs will need also the mapping to edges. > > >I believe that what i am proposing is actually currently called (or at > >least related to) factored use def chains, > > FUD chains are basically SSA without subscripts -- and hence, without > overlapping live ranges. > > >>Ian is right, subregs were a problem (and strict_low_part). I don't > >>recall offhand if it was "normal" subregs or paradoxicals (or both) > >>that caused pain. > > I doubt paradoxical subregs cause any pain. > > >>I haven't looked at the PR in question, but you could probably punt > >>SUBREGs and get the benefits you want for real code on most ports. > >>Yes, someone can (and probably will) contrive an example which does > >>the same thing as your problem PR, but which is littered with SUBREGs > >>in all the "right" places. But the question I think we have to ask at > >>that point is whether or not such code is something we absolutely have > >>to worry about from a compile-time or optimization standpoint. > > Agreed. libcalls, hard registers and operations on parts of registers (subregs, strict low parts etc) as well as match dup are problem for real rewriting SSA form, but not big deal to handle with FUD, since we have separate input/output name and they are all just read-modify-write operations from dataflow POV. Honza > > Paolo