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: RFD, draft patch: IRA costs for reg_equiv_invariant regs


On 06/02/10 15:05, Vladimir Makarov wrote:
Jeff Law wrote:
On 06/02/10 13:17, Vladimir Makarov wrote:
Bernd Schmidt wrote:

On a not-quite-unrelated note, in the 2004 GCC summit proceedings you
write that you had implemented rematerialization. Do you still have the
patch?



Here some code I found. It is very old I have no idea its state but it is enough to get an idea about rematerlization between RA and reload. IMHO, that is where rematerialization should be implemented (reload is another place but it could make reload even more complicated). We discussed it recently with Maxim and I am CCing him too.
I would strongly discourage handling rematerialization in reload. Ideally work on rematerialization would dovetail with my own to split ranges. ie, when an expression is rematerialized, do so into a new pseudo/allocno which is then allocated by the existing ira allocation callbacks.

Right. It is really worth for Bernd and Maxim to look at your branch reload-v2.
Agreed. I'm going to return to the reg_equiv_XXX structure patch, then start looking at the best way to stage in code to generate new pseudos/allocnos between IRA & reload prior to staging in any of the range splitting of unallocated pseudos. My biggest worry is the compile-time cost.

Of course all this is really just setting the stage for the real spilling/reloading work where I need to be able to split ranges based on constraint violations or spill requirements. I've written that code a few times, but never clean enough to even go on a branch :-)

Jeff


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