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: 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~


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