This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: target register load optimizations
On Tue, Jun 10, 2003 at 03:57:18PM +0100, Joern Rennecke wrote:
> The target registers do not only hold branch targets, but are also used
> for function call and return. So calling this a branch register
> optimization would not be factual.
I consider call/return branch instructions as well.
> I suppose if we want to me more specific about what kind of target we
> are talking about here, we have to call it a control flow target.
... I suppose "control flow" would be ok though.
> So before reload, we pretend that jumps and branches that take labels
> for the target exist, but force the labels into target registers with
> reload constraints.
Yes, understood. I don't think we would ever want to do otherwise.
> Your 'optimal' spill code placement algorithm would have to be
> able to hoist input reloads out of loops.
Yes.
> That is what is done for the SH5 by default. A disadvantage of this
> strategy is that the prologue and epilogue have to handle the return
> address, which has to be put into a target register before we can return.
> So prologue and epilogue needs some extra logic to make this work well.
Hmm. I see what you're after here -- the one load of the return
register might possibly be able to be moved up significantly,
depending on the contents of the blocks leading up to it.
> Originally, the pass was done after the prologue/epilogue generation
> (well, to be exact it was in MACHINE_DEPENDENT_REORG initially, but that
> didn't work out). I thought I should leave some choice so people could
> experiment what works best on the SH5 and on other processors as
> the F_CPU.
Ok. Perhaps then we should make this clearer and force the pass
to be run only once. At present your switches allow it to be
run twice.
r~