[PATCH] ira: Respect HARD_REGNO_CALL_PART_CLOBBERED

Jeff Law law@redhat.com
Fri Nov 5 16:30:00 GMT 2010


  On 11/05/10 10:08, Vladimir Makarov wrote:
> On 11/05/2010 11:21 AM, Jeff Law wrote:
>>  On 11/05/10 09:00, Vladimir Makarov wrote:
>>>
>>> First of all, the right solution would be fixing the problem for 
>>> -fcaller-saves case also in caller-saves.c which ignores 
>>> HARD_REGNO_CALL_PART_CLOBBERED at all.  IRA takes already the macro 
>>> into account for the cost calculation in assumption that 
>>> caller-saves.c will save/restore them.
>>>
>>> But it is much bigger job so you could ignore this especially 
>>> because I am not a reviewer of caller-saves.c.
>> Agreed.  Though I could certainly review such a change to 
>> caller-save.c.  Sigh, one day I want caller-save.c to go away :-)
>>
> The simplest way to remove caller-saves.c would be an additional pass 
> before reload which inserts save/restore for pseudos should be saved 
> and prevention of assigning call clobbered registers to pseudos living 
> through calls in reload (plus some inheritance work).  The pass could 
> do it in function scope not in BB scope.  Still it is a lot of work 
> and the results (I mean performance and compilation speed) are not 
> predictable at least for me.

caller-saves is in effect just a special case of range splitting which 
splits the range of hard regs at call boundaries.  I guess that model 
made sense 20 years ago and when I did the last major update to 
caller-save, I didn't try and change the fundamental model.

I think if we turn things around a little bit and model it as range 
splitting on pseudos I think the problem gets much easier to tackle.

caller-saves is pretty cheap compile-time wise right now, but with the 
additional info we have during allocation these days I bet we can 
rewrite it  and stay within the original compile-time budget.   We'll 
obviously have to keep an eye on the runtime aspects as well, but I 
would be surprised if we can't do better than the current implementation 
given what's been learned through the last two decades.


> It is great to have you back, Jeff.  Probably I'll need your help in 
> ira-improv branch reviewing before next stage 1.  Meanwhile I am going 
> to do some job on the branch and try new things.
Yup.  It's on my list, a few back in the queue, mostly because of the 
sheer size of the patches.

jeff



More information about the Gcc-patches mailing list