RFD, draft patch: IRA costs for reg_equiv_invariant regs

Bernd Schmidt bernds@codesourcery.com
Fri May 7 19:38:00 GMT 2010


There are a number of PRs (42500, 42502, 40615, 39871) for the same
problem: a pseudo is set to an invariant (e.g. sp + constant), and IRA
allocates a hard register for it rather than letting register
elimination substitute it into addresses or other moves.  This means we
keep an unnecessary setup insn around.

My first attempt was a patch that made fwprop propagate these invariant
regs into their uses, but whenever I tested it it produced lower SPEC
scores on ARM and i686, so I dropped that approach.

The real problem is that IRA has no concept of the cost of not
allocating such a pseudo register, it just uses the normal memory cost
even though normally no memory moves are involved if the pseudo does not
get a hard register.

The following patch fixes it.  We run a preliminary register elimination
pass from IRA, before calculating costs.  This gives us information
about whether the initial set can be eliminated and whether the
equivalent expression can be substituted into memory addresses or other
operands without reloading.  If any of these is not possible, we can
gather the approximate costs we'll incur.

PR39871 isn't actually fixed yet since the whole reg_equiv_invariant
machinery is apparently turned off by flag_pic.  That's something for a
followup patch.

Bootstrapped and tested on i686-linux (the tested version was slightly
earlier, before I fixed warnings that broke bootstrap).  I've also
backported this to CodeSourcery's 4.4 compiler and run SPECint2000 on
Cortex-A9, where the overall result tied the best result I'd previously
got from that compiler.

Ok?  I'll probably check in a preliminary patch that just moves code
around without adding the other changes.


Bernd
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ira-elim3.diff
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20100507/66e0eee0/attachment.ksh>


More information about the Gcc-patches mailing list