On 2/13/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
Wow, I got so many emails. I'll try to answer them in one email in Let us look at major RTL optimizations: combiner, scheduler, RA.
...PRE, CPROP,SEE, RTL loop optimizers, if-conversion, ... It is easy to make your arguments look valid if you take it as a proposition that only register allocation and scheduling ought to be done on RTL. The reality is that GIMPLE is too high level (by design) to catch many useful transformations performed on RTL. Tthink CSE of lowered addresses, expanded builtins, code sequences generated for bitfield operations and expensive instructions (e.g. mul, div). So we are going to have more RTL optimizers than just regalloc and sched. Many RTL optimizations still matter very much (disable some of them and test SPEC again, if you're unconvinced). Having a uniform dataflow framework for those optimizations is IMHO a good thing.
Do we need a global analysis for building def-use use-def chains? We don't need it for combiner (only in bb scope)
It seems to me that this limitation is only there because when combine was written, the idea of "global dataflow information" was in the "future work" section for most practical compilers. So, perhaps combine, as it is now, does not need DU/UD chains. But maybe we can improve passes like this if we re-implement them in, or migrate them to a better dataflow framework. Gr. Steven
