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
- From: Jeff Law <law at redhat dot com>
- To: Vladimir Makarov <vmakarov at redhat dot com>
- Cc: Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>, gcc-patches at gcc dot gnu dot org
- Date: Fri, 05 Nov 2010 10:28:03 -0600
- Subject: Re: [PATCH] ira: Respect HARD_REGNO_CALL_PART_CLOBBERED
- References: <20101021171457.GA6994@bart> <4CD41BFB.9070706@redhat.com> <4CD420EA.4000701@redhat.com> <4CD42C0F.8030907@redhat.com>
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