Vladimir Makarov wrote: > On Sunday I had accidentally chat about the df infrastructure on > IIRC. I've got some thoughts which I'd like to share. > > I like df infrastructure code from the day one for its clearness. > Unfortunately users don't see it and probably don't care about it.
You're right that users don't care what the guts of the compiler look like. That's exactly right: they care only about about the speed of the compiler, the speed of the generated code, correctness of the generated code, overall quality, etc. However, my understanding (as someone who's not an expert on the DF code base) is that, as you say, the new stuff is much tidier. I understood the objective to be not so much that DF itself would directly improve the generated code, but rather than it would provide much-need infrastructure that would allow future improvements. This is a lot like TREE-SSA which, by itself, wasn't so much about optimization as it was about providing a platform for optimization. Obviously, making sure that the DF code isn't actively hurting us when it goes into the compiler is part of the agreed-upon criteria. But, I don't think it needs to markedly help at this point, as long as people are comfortable with the interfaces and functionality it provides. > So could be somebody from steering committee be kind and answer me > > Is it (prohibiting to use other dataflow schemes) steering committee > decision? No, the Steering Committee has not considered this issue. As you suggest, I don't think it's something the SC would want to consider; it's a technical issue. I'd certainly think that it would be good for all passes to use the DF infrastructure. However, if there were really some special case where we could do markedly better without it, and no feasible way to give the special-case information to the core DF code, then I'm sure everyone would agree that it made sense to use something different. But, that would be only in extraordinary situations, rather than having lots of reinvention of the same infrastructure. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
