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

[Joern Rennecke]

> Ideally, we should have tests to tell whether a branch can be
> redirected, and even some form of emitting such branches that might
> attempt to find a branch-target register available, but I haven't got
> that far.  Currently, a lot of code just assumes that branches can be
> redirected, and it's then hard to revert the effects when we get to
> the point of realizing it was not possible to redirect the branch,
> after all.

We have some local code here at SuperH, written by Stephen Clarke, that
we are considering to contribute.  It estimates the execution frequency
of basic blocks according to their loop depth, and re-allocates target
registers and changes their loads so that they are loaded in less frequently
executed blocks.  This is can be done at two different points after reload -
once at the start of flow2, and the other time just after register renaming.

Considering that the SH5 seems not to remain the only processor with this
requirement, I was thinking of generalizing the code so that it can be used
by multiple targets.
Actually, the code can be used for non-target registers as well, but I'm not
sure if there is a point in making it that general.

Basically, we have
- a register class where the registers can be used interchangably.
- loads of these registers with function invariants, which we can
  optimize, uses of these registers, which we have to observe when
  doing these optimizations, and possibly loads which we can't optimize
  because they do not load a function invariant (or use a register in the
  optimized register class in the source, the code is not designed to
  track this).

We could have a simple macro for the register class - that could yield different
values depending on compiler options.
Or we can have a macro that is expected to hold a NO_REGS array
initializer, which can name multiple register classes - but then, it would
have to be constant. 
Or we can have a macro that takes a numerical parameter, which we increase from
zero by steps of 1 till we get NO_REGS.

We can have different variants of this macro for the different times we can
invoke this optimization, or we can control the invokation time(s) by separate
macros.
Any preferenes?

-- 
--------------------------
SuperH (UK) Ltd.
2410 Aztec West / Almondsbury / BRISTOL / BS32 4QX
T:+44 1454 465658