RFA [PR rtl-optimization/37273] [4.4/4.5/4.6 Regression] IRA does not re-materializes addresses (loads from the TOC)

[Jeff Law <law at redhat dot com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


The basic problem with this regression is IRA calculates that it's
cheaper to hold a symbolic constant in a call-clobbered register which
crosses calls than to just leave it in memory.  The net result is an
extra save into the stack, a load from the stack, a reg->reg copy and
increased stack size.

The IRA dumps clearly showed that IRA computed the cost of the hard regs
to be significantly cheaper than the cost of keeping the allocno in mem.

The first step is to realize that a symbolic constant living in memory
(TOC references, constant pools, etc) represents a savings for any insn
which loads the value from memory into a pseudo.  This is analogous to
the savings we get when loading an argument from its stack slot.

With that change IRA will compute the cost of memory and the cost of
putting the value into a call-clobbered hard register as equal.

The next issue is to realize that once we've accounted for the savings
of leaving the value in memory for a particular insn, we should not then
add in a cost for leaving the value in memory (essentially negating the
savings we realized).

With both changes IRA realizes the allocno is best left in memory and we
get the desired code for PPC.

Interestingly enough the double-counting memory costs was introduced
during IRA development.  Prior to IRA's introduction, once we detected
an argument load from a stack slot and realized the gain from leaving
the value in memory, scan_one_insn returned.  That was changed because
the code generally improved.  My theory is the code improved because we
had been failing to account for costs for the different register classes
in the case where it ultimately wasn't profitable to keep the object in
memory.

My proposed change gives us the best of both worlds.  We realize the
savings from leaving certain objects in memory, but also account for the
costs of keeping them in registers if (due to other insns) registers
turn out to be more profitable.

Bootstrapped and regression tested on x86_64-unknown-linux-gnu.
Verified we get the desired code for powerpc64-unknown-linux.  Verified
we consistently get better code density for x86_64-unknown-linux-gnu.

Also ran spec2k6.  Testing was mostly a wash, with the exception of a
large improvement for 454.calculix.  Both integer and FP specmarks
increased by .1.

OK for trunk?

Jeff


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNOcWMAAoJEBRtltQi2kC7c0sH/iyLZmoz5XnJ/+J+v1BBHDeJ
UCZmspym0OKFkQFCutgeFcEiZ4t931V9tJDMqWzKqkdGP4pmvkBZVlBrSglwTnV5
vFbPasMmayK4fnc3Tu8MWtabjHv/Zqq7J7keb+6uZ7oBwcpdVuk7KUo48UX++HxG
gXW5WsR5AZiwGb8RGzP3nKl4PMfBDeOHa1uAr58565C75ld2yS6Rf24DGbz6maF8
KEgfY63LSNrOsXoZwtkeIAP9jtNZ5Oo34V54wpLs4HtRdWyE3NVX9L24WL2EJDnb
SbAyWMpaO28o8UarrvlqfJcJmfVdz+CoF+p0on8Y2LRGDAIeyt6B36LKvq6x/ck=
=wxcV
-----END PGP SIGNATURE-----

Attachment: P
Description: Text document