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

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

[steven at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211

Bug 20211 depends on bug 19078, which changed state.

Bug 19078 Summary: Poor quality code after loop unrolling.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19078

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |DUPLICATE

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

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211

Oleg Endo <olegendo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |sh*-*-*
                 CC|                            |olegendo at gcc dot gnu.org

--- Comment #40 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Just hit this PR by accident.  I wonder how many address mode related PRs are
hanging around there...

I hope that the AMS pass will help.  The current branch is
https://github.com/erikvarga/gcc

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

[amylaar at gcc dot gnu dot org]

------- Comment #39 from amylaar at gcc dot gnu dot org  2010-02-22 06:04 -------
(In reply to comment #38)
> Maybe this issue migrated into PR31849?

Not entirely, PR31849 is tree-optimization, and a lot of auto-increment
opportunities are only visible at the rtl level.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211

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

[hp at gcc dot gnu dot org]

------- Comment #38 from hp at gcc dot gnu dot org  2008-05-23 23:13 -------
Maybe this issue migrated into PR31849?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211

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

[rguenth at gcc dot gnu dot org]

------- Comment #37 from rguenth at gcc dot gnu dot org  2007-09-17 20:06 -------
No 4.3 pending patch anymore.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|28177                       |
              nThis|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211

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

[pinskia at gcc dot gnu dot org]

------- Comment #36 from pinskia at gcc dot gnu dot org  2007-06-18 02:03 -------
Just removing patch keyword as the patch is no longer applies after the
dataflow branch merge.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|http://gcc.gnu.org/ml/gcc-  |
                   |patches/2005-               |
                   |09/msg01176.html            |
           Keywords|patch                       |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211

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

[steven at gcc dot gnu dot org]

------- Comment #35 from steven at gcc dot gnu dot org  2006-12-17 14:47 -------
This should be fixed when the dataflow branch is merged.  There is a new pass
there dedicated to generating auto-inc/dec insns.  If the pass in
auto-inc-dec.c on the dataflow branch does not fix this issue, a proper fix for
this bug will have to be implemented there instead of in regmove.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211

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

[amylaar at gcc dot gnu dot org]

------- Comment #34 from amylaar at gcc dot gnu dot org  2006-11-30 20:04 -------
Created an attachment (id=12718)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12718&action=view)
add-on patch

I've found that this patch is also necessary to avoid invalid transformations.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211

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

[amylaar at gcc dot gnu dot org]

------- Comment #33 from amylaar at gcc dot gnu dot org  2006-11-15 20:11 -------
4.x patches:
http://gcc.gnu.org/ml/gcc-patches/2006-06/msg01184.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211

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

[amylaar at gcc dot gnu dot org]

------- Comment #32 from amylaar at gcc dot gnu dot org  2005-11-02 21:50 -------
Subject: Bug 20211

Author: amylaar
Date: Wed Nov  2 21:50:22 2005
New Revision: 106401

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106401
Log:
Belated Makefile.in checkin for:

2005-09-19  J"orn Rennecke <joern.rennecke@st.com>
            Bernd Schmidt  <bernds@redhat.com>

        PR rtl-optimization/20211
        http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01176.html
        * common.opt: Add optimize-related-values entry.
        * opts.c (decode_options): Set flag_optimize_related_values.
        * optabs.c (gen_add3_insn): If direct addition is not possible,
        try to move the constant into the destination register first.
        * regmove.c (obstack.h, ggc.h, optabs.h): Include.
        (related, rel_use_chain, rel_mod, rel_use): New structures.
        (related_baseinfo, update): Likewise.
        (lookup_related, rel_build_chain): New functions.
        (recognize_related_for_insn, record_reg_use, create_rel_use): Likewise.
        (new_reg_use, rel_record_mem, new_base, invalidate_related): Likewise.
        (find_related, find_related_toplev, chain_starts_earlier): Likewise.
        (chain_ends_later, mod_before, remove_setting_insns): Likewise.
        (perform_addition, modify_address): Likewise.
        (optimize_related_values_1, optimize_related_values_0): Likewise.
        (optimize_related_values, count_sets, link_chains): Likewise.
        (init_add_limits): Likewise.
        (REL_USE_HASH_SIZE, REL_USE_HASH, rel_alloc, rel_new): New macros.
        (regno_related, rel_base_list, unrelatedly_used): New variables.
        (related_obstack, add_limits): Likewise.
        (regmove_optimize): Call optimize_related_values.
        Include gt-regmove.h.
        (have_3addr_const_add): New variable.
        * Makefile.in (gt-regmove.h): New rule.
        (regmove.o): Depend on $(OPTABS_H) and gt-regmove.h.
        (GTFILES): Add regmove.c.
        * doc/invoke.texi: Document -foptimize-related-values.

Modified:
    branches/sh-elf-4_1-branch/gcc/Makefile.in


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211

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

[amylaar at gcc dot gnu dot org]

------- Additional Comments From amylaar at gcc dot gnu dot org  2005-09-19 17:30 -------
Test results for sh-elf-4_1-branch with
http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01176.html
are:
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00925.html
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00926.html
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00927.html


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://gcc.gnu.org/ml/gcc-
                   |                            |patches/2005-
                   |                            |09/msg01176.html


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211

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

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-09-19 16:54 -------
Subject: Bug 20211

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	sh-elf-4_1-branch
Changes by:	amylaar@gcc.gnu.org	2005-09-19 16:54:05

Modified files:
	gcc            : ChangeLog common.opt optabs.c opts.c regmove.c 

Log message:
	2005-09-19  J"orn Rennecke <joern.rennecke@st.com>
	Bernd Schmidt  <bernds@redhat.com>
	
	PR rtl-optimization/20211
	* common.opt: Add optimize-related-values entry.
	* opts.c (decode_options): Set flag_optimize_related_values.
	* optabs.c (gen_add3_insn): If direct addition is not possible,
	try to move the constant into the destination register first.
	* regmove.c (obstack.h, ggc.h, optabs.h): Include.
	(related, rel_use_chain, rel_mod, rel_use): New structures.
	(related_baseinfo, update): Likewise.
	(lookup_related, rel_build_chain): New functions.
	(recognize_related_for_insn, record_reg_use, create_rel_use): Likewise.
	(new_reg_use, rel_record_mem, new_base, invalidate_related): Likewise.
	(find_related, find_related_toplev, chain_starts_earlier): Likewise.
	(chain_ends_later, mod_before, remove_setting_insns): Likewise.
	(perform_addition, modify_address): Likewise.
	(optimize_related_values_1, optimize_related_values_0): Likewise.
	(optimize_related_values, count_sets, link_chains): Likewise.
	(init_add_limits): Likewise.
	(REL_USE_HASH_SIZE, REL_USE_HASH, rel_alloc, rel_new): New macros.
	(regno_related, rel_base_list, unrelatedly_used): New variables.
	(related_obstack, add_limits): Likewise.
	(regmove_optimize): Call optimize_related_values.
	Include gt-regmove.h.
	(have_3addr_const_add): New variable.
	* Makefile.in (gt-regmove.h): New rule.
	(regmove.o): Depend on $(OPTABS_H) and gt-regmove.h.
	(GTFILES): Add regmove.c.
	* doc/invoke.texi: Document -foptimize-related-values.
	
	2005-09-19  J"orn Rennecke <joern.rennecke@st.com>
	
	* regmove.c (discover_flags_reg): Use the PATTERN of an INSN.
	
	* regmove.c (fixup_match_1): When moving a death note, check if
	it needs changing into a REG_UNUSED note.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=sh-elf-4_1-branch&r1=2.8142.2.30&r2=2.8142.2.31
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/common.opt.diff?cvsroot=gcc&only_with_tag=sh-elf-4_1-branch&r1=1.66.2.3&r2=1.66.2.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/optabs.c.diff?cvsroot=gcc&only_with_tag=sh-elf-4_1-branch&r1=1.268.2.4&r2=1.268.2.5
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/opts.c.diff?cvsroot=gcc&only_with_tag=sh-elf-4_1-branch&r1=1.99.2.3&r2=1.99.2.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/regmove.c.diff?cvsroot=gcc&only_with_tag=sh-elf-4_1-branch&r1=1.166.18.2&r2=1.166.18.3



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211

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

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-09-19 16:52 -------
Subject: Bug 20211

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	sh-elf-4_1-branch
Changes by:	amylaar@gcc.gnu.org	2005-09-19 16:52:39

Modified files:
	gcc/doc        : invoke.texi 

Log message:
	2005-09-19  J"orn Rennecke <joern.rennecke@st.com>
	Bernd Schmidt  <bernds@redhat.com>
	
	PR rtl-optimization/20211
	* common.opt: Add optimize-related-values entry.
	* opts.c (decode_options): Set flag_optimize_related_values.
	* optabs.c (gen_add3_insn): If direct addition is not possible,
	try to move the constant into the destination register first.
	* regmove.c (obstack.h, ggc.h, optabs.h): Include.
	(related, rel_use_chain, rel_mod, rel_use): New structures.
	(related_baseinfo, update): Likewise.
	(lookup_related, rel_build_chain): New functions.
	(recognize_related_for_insn, record_reg_use, create_rel_use): Likewise.
	(new_reg_use, rel_record_mem, new_base, invalidate_related): Likewise.
	(find_related, find_related_toplev, chain_starts_earlier): Likewise.
	(chain_ends_later, mod_before, remove_setting_insns): Likewise.
	(perform_addition, modify_address): Likewise.
	(optimize_related_values_1, optimize_related_values_0): Likewise.
	(optimize_related_values, count_sets, link_chains): Likewise.
	(init_add_limits): Likewise.
	(REL_USE_HASH_SIZE, REL_USE_HASH, rel_alloc, rel_new): New macros.
	(regno_related, rel_base_list, unrelatedly_used): New variables.
	(related_obstack, add_limits): Likewise.
	(regmove_optimize): Call optimize_related_values.
	Include gt-regmove.h.
	(have_3addr_const_add): New variable.
	* Makefile.in (gt-regmove.h): New rule.
	(regmove.o): Depend on $(OPTABS_H) and gt-regmove.h.
	(GTFILES): Add regmove.c.
	* doc/invoke.texi: Document -foptimize-related-values.
	
	2005-09-19  J"orn Rennecke <joern.rennecke@st.com>
	
	* regmove.c (discover_flags_reg): Use the PATTERN of an INSN.
	
	* regmove.c (fixup_match_1): When moving a death note, check if
	it needs changing into a REG_UNUSED note.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/invoke.texi.diff?cvsroot=gcc&only_with_tag=sh-elf-4_1-branch&r1=1.598.2.4&r2=1.598.2.5



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211

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

[amylaar at gcc dot gnu dot org]

------- Additional Comments From amylaar at gcc dot gnu dot org  2005-05-17 19:20 -------
updated patch:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01768.html

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211

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

[joern dot rennecke at st dot com]

------- Additional Comments From joern dot rennecke at st dot com  2005-05-12 19:30 -------
Subject: Re:  autoincrement generation is poor

pinskia at gcc dot gnu dot org wrote:

>------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-12 18:59 -------
>The only change is the following:
>before:
>bzip2-1.0.2,compress,9408
>bzip2-1.0.2,decompress,10604
>after:
>bzip2-1.0.2,compress,9428
>bzip2-1.0.2,decompress,10640
>
>  
>
Well, there were also lots of small changes.  As said before, if you add 
it all up, the net difference is just four bytes.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-12 18:59 -------
The only change is the following:
before:
bzip2-1.0.2,compress,9408
bzip2-1.0.2,decompress,10604
after:
bzip2-1.0.2,compress,9428
bzip2-1.0.2,decompress,10640

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211

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

[amylaar at gcc dot gnu dot org]

------- Additional Comments From amylaar at gcc dot gnu dot org  2005-04-28 19:21 -------
An updated patch is here:
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg02898.html

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-28 13:42 -------
(In reply to comment #10)
> (In reply to comment #9)
> > Mac OS X and darwin works on the G3, just fine.
> 
> The Mac OS X tiger system requirements say that it needs built-in firewire.
> This Mac doesn't have firewire.  It also came with 32 MB RAM originally,
> although it has been upgraded to 384 MB.

Oh, it is a Yikes, oh well.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211

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

[amylaar at gcc dot gnu dot org]

------- Additional Comments From amylaar at gcc dot gnu dot org  2005-04-28 13:36 -------
(In reply to comment #9)
> Mac OS X and darwin works on the G3, just fine.

The Mac OS X tiger system requirements say that it needs built-in firewire.
This Mac doesn't have firewire.  It also came with 32 MB RAM originally,
although it has been upgraded to 384 MB.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-27 13:41 -------
(In reply to comment #8)
> (In reply to comment #4)
> > 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 have been trying to install Linux/GNU on an POwer Macintosh G3, but it
> appears that this is not going to work.  Inserting a Yellowdog 3.0.1
> install 1 CD-rom into the drive freezes the machine solid.  BootX versions
> later than BootX_1.1.3 won't unpack.  BootX 1.1.3 freezes the machine about
> 60% of the time rather than starting a kernel.  rocklinux gets a CRC error
> on the ramdisk and then can't find init.  ubuntu manages to continue after
> ramdisk unpacking errors, and even goes as far as partitioning if you
> restrict the partitions to 13 GB or less, but then it say it can't find the
> CD_ROM it just has read lots of files from.

Mac OS X and darwin works on the G3, just fine.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211

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

[amylaar at gcc dot gnu dot org]

------- Additional Comments From amylaar at gcc dot gnu dot org  2005-04-27 13:37 -------
(In reply to comment #4)
> 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 have been trying to install Linux/GNU on an POwer Macintosh G3, but it
appears that this is not going to work.  Inserting a Yellowdog 3.0.1
install 1 CD-rom into the drive freezes the machine solid.  BootX versions
later than BootX_1.1.3 won't unpack.  BootX 1.1.3 freezes the machine about
60% of the time rather than starting a kernel.  rocklinux gets a CRC error
on the ramdisk and then can't find init.  ubuntu manages to continue after
ramdisk unpacking errors, and even goes as far as partitioning if you
restrict the partitions to 13 GB or less, but then it say it can't find the
CD_ROM it just has read lots of files from.

So, since there is no native platform I can test, would you like me to
benchmark cross-compiling a suitable package?  IIRC powerpc-eabisim is
a possible cross target.  Would CSIBE cross-compile time measurements
fit your requirements?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211

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

[amylaar at gcc dot gnu dot org]

------- Additional Comments From amylaar at gcc dot gnu dot org  2005-04-12 18:06 -------
This code is waiting for review since 1999:

http://gcc.gnu.org/ml/gcc-patches/1999-11n/msg00583.html

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |17652
              nThis|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211

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

[amylaar at gcc dot gnu dot org]

------- Additional Comments From amylaar at gcc dot gnu dot org  2005-03-17 16:37 -------
(In reply to comment #4)
> 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 currently don't have an ARM or RS6000 platform to run benchmarks on.
We are looking into setting up a powermac for this task, though.
AFAICS RS6000 provides register+offset addressing for all modes except the
altivec vector modes, so to see any significant benefit from
optimize_related_values, the benchmark should have multiple altivec memory
accesses from the same structure / array in a single basic block.

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

I am willing to make that change, but would first like to hear from a global
or middle-end maintainer that they agree that this is a move in the right direction.
Also, there are some details that should be agreed on first.
I.e.:
Should tehre remain a toplevel regmove function that calls 
mark_flags_life_zones first, and then the sub-passes, or should
each sub-pass call mark_flags_life_zones?
If there is such a toplevel functiojn, would it live in the regmove*
files, or would that be rest_of_handle_regmove in passes.c ?
Where does the combine_stack_adjustments pass belong?  Should it
be in flow.c, or in it's own file (combine_stack_adj.c ?)

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211

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

[amylaar at gcc dot gnu dot org]

------- Additional Comments From amylaar at gcc dot gnu dot org  2005-03-15 18:08 -------
> A patch against 4.0 20050218 is here:
> http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01612.html

discover_flags_reg also needs to be updated to understand INSNs.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211

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

[giovannibajo at libero dot it]

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

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

[joern dot rennecke at st dot com]

------- Additional Comments From joern dot rennecke at st dot com  2005-02-28 13:46 -------
Subject: Re:  autoincrement generation is poor

giovannibajo at libero dot it wrote:

>------- Additional Comments From giovannibajo at libero dot it  2005-02-25 18:59 -------
>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 (in principle it is possible to use it to reduce 
register pressure on
other targets too, but there is also a cost to pay in reduced 
flexibility for sched2 till you make
the scheduler aware of the possible transformations).
Note that there is a specific flag to enable or disable this 
optimization, so for each target this
can be tuned by OPTIMIZATION_OPTIONS.  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.

>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.
For the c4x, it would make sense to run this pass earlier, as detailed 
in the 1999 thread.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211

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

[hp at gcc dot gnu dot org]

------- Additional Comments From hp at gcc dot gnu dot org  2005-02-26 12:56 -------
(Interested because I see this for CRIS too.  For CRIS v32, it's even more
interesting, because it has no reg+offset addressing.)

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hp at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211

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

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2005-02-25 18:59 -------
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.

And BTW, out of curiosity, does the new pass have to live in regmove.c?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-02-25 18:59:53
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211

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

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211