This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/33699] [4.2/4.3/4.4 regression], missing optimization on const addr area store
- From: "amylaar at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 8 Feb 2009 12:49:34 -0000
- Subject: [Bug middle-end/33699] [4.2/4.3/4.4 regression], missing optimization on const addr area store
- References: <bug-33699-1573@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #4 from amylaar at gcc dot gnu dot org 2009-02-08 12:49 -------
(In reply to comment #2)
> This is related to some work done in the past for auto-increment addressing
> modes
Actually, the problem with constants that are loaded into registers -
and in the same basic block, at that - is much simpler.
If the targets rtx_cost works properly, then reload_cse_move2add should
fix up this code.
We need, however, some way to deal with the case where constants are expensive
addresses; this is completely broken at the moment. Complete unrolling of
loops accessing static arrays can create oodles of constant addresses; I've
managed to split these up with LEGITIMIZE_ADDRESS, the movsi expander, and
a patch to momory_address, however, gcse just recombines the costly constants,
irrespective of what rtx_cost and address_cost says.
And the havoc that gcse can wreak transcends basic blocks, so any attempt to
clean up after if with lesser scope is bound to be inferior.
--
amylaar at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amylaar at gcc dot gnu dot
| |org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33699