This is the mail archive of the
mailing list for the GCC project.
Re: IRA_COVER_CLASSES In gcc47
On 12-03-23 3:47 PM, FrÃdÃric RISS wrote:
Hi ValdimirIt is not that definitely. There are some rare cases, when trivially
colored pseudos do not get hard regs (e.g. mix of one and mult-reg
pseudos or when the cost of regs for pseudos was changed during
assinging pass). But the smaller number of such cases, the better
implementation of coloring.
Le vendredi 23 mars 2012 Ã 12:08 -0400, Vladimir Makarov a Ãcrit :
Since 4.7 we use more sophisticated trivial coloring criteria which work
well even on intersected register classes. To be more accurate, we
calculate an approximation of an profitable hard regs for each pseudo.
These approximations form a tree. The tree is used for find trivial
colorability of the pseudos. It was a surprise that such approach is
profitable even for architectures with regular register files like ppc.
Here is an excerpt from comments on the top ira.c file:
I started porting an in house backend to GCC 4.7 and saw at least one
huge regression relating to the IRA changes. The symptom in that
benchmark is that all allocnos get pushed on the allocation stack as
trivially colorable, but at unstacking time only the first ones get a
hard reg and all others get spilled.
AFAIU the CB coloring algorithm, all registers that get pushed as
trivially colorable should get a hard reg when they are popped from the
stack. Thus there must be some description issue in my backend that
confuses the IRA.
It might be because of situation of mult-regs pseudos requiring
aligning. The best way to say something more definitely is to send me
ira dump file for this case of course if it is ok for you (you could
send it to me only).
The register file is very regular. There are 64 SImode registers of
which 3 are fixed. In order to store DImode values, 2 consecutive SImode
registers are needed. The DImode pairs cannot be chosen anywhere in the
register file, they need to start at even offset (however this still
allows to have 32 DImode registers).
In the testcase I'm looking at, we have ~32 DImode allocnos that are
live from function start to the end. These registers conflict with
(nearly) all other allocnos. These registers get pushed last, but
strangely, they get pushed as trivially colorable. Of course, once the
register file has been fully allocated to these long lived registers,
nothing else can get a hard register anymore.
In GCC 4.5, some of these DImode registers got marked as potential
spill, and allowed the other pseudos to be correclty allocated.
Do you have any idea what in my backend can confuse the trivial coloring
criteria to mark all allocnos as trivially colorable ?
It would be even better if you send ira dump file for gcc 4.6 for the
same test. Of course, it is possible.