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

Re: IRA_COVER_CLASSES In gcc47


On 12-03-23 3:47 PM, FrÃdÃric RISS wrote:
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.
It 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.
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 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).

It would be even better if you send ira dump file for gcc 4.6 for the same test. Of course, it is possible.

Many thanks,
Fred



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