Chris Lattner wrote: > I totally agree with Steven on this one. It is *good* for the > representation hosting optimization to be different from the > representation you use to represent a program at source level. The two > have very different goals and uses, and trying to merge them into one > representation will give you a representation that isn't very good for > either use.
I don't think that's entirely true. One of the nice things about WHIRL, at least in theory, is that the representation is gradually lowered throughout the compiler, but is never abruptly transitioned, as with GCC's Tree->RTL conversion. So, it's easier to reuse code, instead of having a Tree routine and an RTL routine that do "the same thing", as we do in several places in GCC. As a concrete example, having a control-flow graph in the front-end is very useful, for optimization purposes, diagnostic purposes, and for plugging in domain-specific optimizers and analyzers. It would be nice to have flow-graph code that could be easily used in both places, without having to make that code representation-independent, using adapters to abstract away the actual representation. That's not to say that I disagree with: > In particular, the optimization representation really does want > something in "three-address" form. The current tree-ssa implementation > emulates this (very inefficiently) using trees, but at a significant > performance and memory cost. The representation you want for > source-level information almost certainly *must* be a tree. Instead, it's a long-winded way of saying that I don't agree that there's any inherent benefit to using completely different representations, but that I do agree that one wants the right representation for the job, and that Tree-SSA is not the best representation for optimization. So, if Tree-SSA is not replaced, it will almost certainly need to evolve. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
