This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Minor improvement to double-word register allocations
- From: Jeff Law <law at redhat dot com>
- To: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 20 May 2010 16:49:08 -0600
- Subject: Minor improvement to double-word register allocations
Back in Sept '09 I stumbled across an unusual allocation from IRA.
We're in the process of coloring a DImode allocno that wants
GENERAL_REGS (x86).
At the time of coloring none of the conflicting allocnos have a color,
so we're free to choose any register within GENERAL_REGS. Clearly our
selection should be driven entirely by cost analysis.
For the allocno in question we have these costs before taking the
preferences of conflicting allocnos into account:
(gdb) p costs[0]@8
$106 = {-90110, 0, 0, 0, 0, 0, 0, 0}
Which seems to indicate that we should assign hard register 0 to this
allocno, all else being equal.
After adjusting costs for the preferences of conflicting allocnos we have:
(gdb) p full_costs[0]@8
$107 = {1376235, 0, 0, 0, 0, 0, 0, 0}
Which I believe says that "some other allocnos that we conflict with
really need hard register 0."
So with those costs assign_hard_reg selects the first register with the
smallest cost which happens to be register 1.
As it turns out register 1 (or any odd numbered register) is a horrible
choice -- any time we select an odd register for a DImode value on x86
we've insured that we can assign hard registers for no more than 2 other
DImode values when this allocno is live.
So while the x86 has no restrictions on what hard registers start a
DImode register pair, it is advantageous to first try to an aligned
register pair, then fall back to an unaligned pair. Obviously for
targets which don't allow multi-word regs to start on an unaligned
register, this isn't a problem.
Vlad & I poked at a couple different approaches to address this issue.
What seemed to work best was Vlad's twiddle to show using an unaligned
register for the start of a multi-register allocation was slightly more
expensive than using an aligned register.
I've been using this patch for about 6 months on the reload-v2 branch
(including bootstrapping x86 rather than x86_64 for a while) -- I also
bootstrapped and regression tested the patch using the mainline sources
on x86_64-unknown-linux-gnu.
Approved and installed.
Attachment:
P
Description: Text document