This is the mail archive of the 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]


Hi Valdimir

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.

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 ?

Many thanks,

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