------- Additional Comments From giovannibajo at libero dot it 2005-03-15 02:12 ------- (In reply to comment #3)
>> What is the compile-time impact of this patch on cc-i compilation, the usual >> C++ testcases, and SPEC? I am sure this is something worthwile to >> mention for a review. > Sorry, I don't have such numbers at the moment. Note that this > optimization is specific to AUTO_INC_DEC targets There are both primary and secondary platforms among the AUTO_INC_DEC targets. So it is probably good to gain some wider test coverage about the compile- time/run-time impact of this. E.g. testing CSIBE on ARM, or SPEC on RS6000. > I made this switch default-on at > -O2 mainly because it makes testing the patch much simpler. > For integration, I'm also fine with having it > default-off and having only the targets that want it turn it on in > OPTIMIZATION_OPTIONS. IMHO it is better to activate new optimization passes at either -O2 or -O3, depending on their impact on compile time and code generation (see above). So I am fine with that once it is proven that this is doing well. > >And BTW, out of curiosity, does the new pass have to live in regmove.c? > Not absolutely, but it makes sense insofar as an aspect of this > optimization is to avoid register-register > moves which are required when you end up with awkward register > assignments for the addds, > and it is also nice to have sched1 run first. And there is also the > issue fo inserting add instructions, > which needs infrastructure from regmove to avoid issues with targets > that have a flags register that > can be clobbered by the new adds. One of the common complaints of RTL code is that monolithic files containing multiple optimization passes (with interwinded functions) and with undocumented public interface is a maintenance mess. Compare that with tree-ssa where each pass lives in its own small[1] file and just exposes the pass description structure. I believe it would be great if the new pass could be live in its own file. The utility functions currently in regmove could be extracted in regmovelib or whatever name fits best. [1] ok, let's ignore ivopts for the sake of this discussion ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211
