This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]