Jeff, 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.
The subregs are clearly going to be the issue, and before i dive into it i want to understand what it means to do a merge a bunch of bunch of subreg stores. We currently have a suite of optimization passes that work on du or ud chains, and they seem to do just fine having a use that is reached by multiple subreg stores. So i guess the first thing is to look to see if each of them is handling them in a similar manner and use that that to construct the merge. The big difference between what i am proposing with birthpoints and a full blown ssa implementation is that i plan to do no rewriting since there are no operands of the phis to support this. It is my hope that by avoiding explicit operands to the phis that i can avoid much of the pain. All that the move will have to do is "cover" all of the parts of the reg that are covered by any of the sets that reach it, including ones that just wound rather than kill. I believe that what i am proposing is actually currently called (or at least related to) factored use def chains, but i need to read up on the literature to see if they really are the same. Reif and Lewis's birthpoint graph was earlier but their papers are in obscure locations and are difficult to read. FUD's appear to have been invented later by the parallelization community without knowledge of Reif and Lewis, but i need to check this for sure. Jeff Law wrote: > Kenneth Zadeck wrote: >> jeff, >> >> i posted this earlier today to the gcc mailing list. I was wondering >> what your feelings were on this. I know you had a hand in the first >> attempt to make the rtl level into ssa form. >> I had asked iant privately if he knew why the it did not work out and he >> said that he thought it had something to do with subregs. I was >> wondering if you would be willing to elaborate on the issues. It is my >> hope, that if we can take the baby step that i propose here, that we can >> approach the issue in small manageable steps rather that a project as >> large and complex as the dataflow branch. > My old HP box is dead, so I don't have my old mail archives which would > have had the internal correspondence between GeoffK, RTH, and myself. > You might find something in the external archives with the right search > terms. You'd be looking for stuff in 1999/2000. > > 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. > > One of the things we utterly failed at was realizing that we could > just punt certain things. If we had a pseudo which was set via a > SUBREG, then we could just ignore it for SSA rewriting like we did > with hard registers. Basically it'd be a flag bit on each pseudo > to indicate whether or not the pseudo was in SSA form. It's not > optimal, but it would be practical for the most common code generated > by the most common ports. Basically we'd treat those pseudos just > like we did for hard regs. One class of problems would have simply > disappeared... Why we didn't see this at the time is beyond me. > > > There was also a certain amount of pain around libcalls, but the > details are totally lost to me. > > 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. > > Jeff
