[Bug rtl-optimization/20211] autoincrement generation is poor

["giovannibajo at libero dot it" <gcc-bugzilla at gcc dot gnu dot org>]

------- 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