target register load optimizations (Was: Re: Porting gcc for F-CPU without direct JMP)

[Stephen Clarke]

Joern Rennecke wrote:

> Stephen Clarke wrote:
> > I would expect that in the current FSF gcc sources, you can use the generic
> > execution frequency information, rather than the loop-depth based
> > frequency estimation we originally had?    This would give
> > profile-directed placement of the target register loads (assuming
> > the profiling feedback option is available on the target).
> 
> Yes, that's a nice extra project.  However, unless you already have code
> for this, I'd like to focus first on getting the interfaces right.

Sure.  Anyhow, I don't have code.  IIRC it should be very straightforward
to replace the execution frequency estimation code, but I haven't looked at
any of this for a long time now, so I don't really know for sure.

> I can imagine  you put the first target register optimization pass before
> jump2 so that the number of branch targets isn't increased too much by
> cross jumping?
> 
> But I can't see why you would want to run the second pass just before
> ifconvert - isn't it better to move it after ifconvert?

Yes, I'd have thought so.  My choice was not that scientific: I was constrained
by the times at which the control-flow info was available (I was working in a
variant of gcc source from c.1999).

I recall trying three places for the pass:
1.  In machine-dependent reorg., chosen so that it did not stray outside
the target-specific code.  Didn't work very well because this is after
scheduling, so the target register load instructions aren't scheduled properly.
Also has problems because it's after reg. alloc., so you can only use
scratch target registers, or ones that are already in use elsewhere in the
CFG.
2.  Before sched2.  Better because you get scheduling of the target register
load instructions.  But you still only have access to touched or scratch target
registers.
3.  Just after reload (I think), but with some unpleasant code to save
space for callee-save target registers in the stack frame.  This allowed
use of all the target registers.
I'm sure this code transgressed the rules for how the stack frame should be
allocated.  But it gave significantly better benchmark results than the first
two.

I only ever measured the performance with target register optimization
enabled in one of these places at any one time.  The algorithm has the
potential to be slow when the dominator tree is deep, so there would have to
be good code improvement to justify multiple passes.

Steve.


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com