This is the mail archive of the gcc-patches@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: [PATCH] ira: Respect HARD_REGNO_CALL_PART_CLOBBERED


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


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