On 31 Dec 2011, at 15:12, Bernd wrote: > My question is now: Will ASMCSE eventually be completely removed?
Probably, yes. > And > if this happens, will there be a replacement? As far as I'm concerned: an LLVM backend (although that's sort of independent of when/whether the ASMCSE optimizer will be removed, because there will probably never be an LLVM port that can e.g. target go32v2, but that in itself won't stop the removal of the ASMCSE optimizer). > IMHO this optimization > is really needed. Is it really so difficult to make an optimizer that > simply (is it simple?) eliminates these redundant register reloads > without being overly complicated and unmaintainable? It's undoubtedly possible to implement this in a way that is much less complex, much easier and much simpler than the current ASMCSE implementation (although I don't think it will ever be really simple, because machine code was never designed to be easily analysable). Apart from being the first somewhat complex code that I ever wrote (it was started 14.5 years ago!) and organically grown over the years, it also does much more than removing simple loads (it can remove entire subsequences and perform register renaming). But such a new implementation would require time, and I'm not aware of anyone willing to invest that time. > he last question > is only because I don't yet know how the code generation and > optimization of FPC even works, I wouldn't even know where to start > looking for it in the compiler sources. * compiler/i386/daopt386.pas: data flow analysis (DFA, collects information about what each register holds) * compiler/i386/csopt386.pas: common subexpression elimination based on information collected by DFA * compiler/i386/rropt386.pas: register renaming based on the information collected by DFA Jonas_______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
