This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] ira: Respect HARD_REGNO_CALL_PART_CLOBBERED
On 11/05/2010 12:28 PM, Jeff Law wrote:
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.
Agree, it could be considered as a special case for live range splitting
and there are many common things with ld/st motion.
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 definitely will be more clear and close to compiler books and
probably more understandable.
Actually, I've tried to implement placement of save/restore code in
global scope and even submitted it as part of IRA. I withdraw it
finally because I did not like the code version of that time and the
improvement were vanishingly small.
I think it is not a problem to implement some form of live-range
splitting. It is much harder to achieve a balance in live-range
splitting and spilling. My experience shows me that too aggressive
splitting results in worse programs (with code size and performance
point of view).
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.
Thanks, Jeff. But I don't think you need to review the patches I
submitted last time because there will changes may be big ones (eg, I am
thinking that ir-color.c became too big and it would be reasonable to
split it). So probably your help will be really needed only in a few
months.