[Bug rtl-optimization/20211] autoincrement generation is poor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211 Steven Bosscher changed: What|Removed |Added Status|NEW |RESOLVED CC|steven at gcc dot gnu.org | Resolution|--- |WONTFIX --- Comment #41 from Steven Bosscher --- After 12 years of changes, the value of the patches in this bug report, and indeed the bug report itself, is difficult to gauge. If this is still an issue, and that issue isn't covered by one of the more specific auto-inc-dec issues, please open a new PR with a test case and with the expected code. For now, wontfix.
[Bug rtl-optimization/20211] autoincrement generation is poor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211 Oleg Endo changed: What|Removed |Added Target||sh*-*-* CC||olegendo at gcc dot gnu.org --- Comment #40 from Oleg Endo --- 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
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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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=12718action=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
--- 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
--- 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=gccview=revrev=106401 Log: Belated Makefile.in checkin for: 2005-09-19 Jorn Rennecke [EMAIL PROTECTED] Bernd Schmidt [EMAIL PROTECTED] 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
--- 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: [EMAIL PROTECTED] 2005-09-19 16:52:39 Modified files: gcc/doc: invoke.texi Log message: 2005-09-19 Jorn Rennecke [EMAIL PROTECTED] Bernd Schmidt [EMAIL PROTECTED] 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 Jorn Rennecke [EMAIL PROTECTED] * 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=gcconly_with_tag=sh-elf-4_1-branchr1=1.598.2.4r2=1.598.2.5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211
[Bug rtl-optimization/20211] autoincrement generation is poor
--- 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: [EMAIL PROTECTED] 2005-09-19 16:54:05 Modified files: gcc: ChangeLog common.opt optabs.c opts.c regmove.c Log message: 2005-09-19 Jorn Rennecke [EMAIL PROTECTED] Bernd Schmidt [EMAIL PROTECTED] 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 Jorn Rennecke [EMAIL PROTECTED] * 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=gcconly_with_tag=sh-elf-4_1-branchr1=2.8142.2.30r2=2.8142.2.31 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/common.opt.diff?cvsroot=gcconly_with_tag=sh-elf-4_1-branchr1=1.66.2.3r2=1.66.2.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/optabs.c.diff?cvsroot=gcconly_with_tag=sh-elf-4_1-branchr1=1.268.2.4r2=1.268.2.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/opts.c.diff?cvsroot=gcconly_with_tag=sh-elf-4_1-branchr1=1.99.2.3r2=1.99.2.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/regmove.c.diff?cvsroot=gcconly_with_tag=sh-elf-4_1-branchr1=1.166.18.2r2=1.166.18.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211
[Bug rtl-optimization/20211] autoincrement generation is poor
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211
[Bug rtl-optimization/20211] autoincrement generation is poor
--- 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|-00-00 00:00:00 |2005-02-25 18:59:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211
