alpha [reload] bug

[Joern Rennecke]

> We've just finished merging with an existing secondary reload.  Surely
> it is not correct to continue attempting to merge with others, then
> fall out of the loop and create a new reload when s_reload == n_reloads.

It should work, but it's certainly not what was intended.  Your added break
makes sense.

> Third, and this is the killer from this example's point of view, is
> that emit_reload_insns creates a new reload via gen_reload.  This 
> happens after choose_reload_regs has been called, so when we get to
> subst_reloads, we've not got a register for the new reload and abort. 
> This one I don't know how to solve, as I don't know how this stuff is
> supposed to interact.

Can you elaborate on this?  How does the backtrace look, etc?

> Fourth, wrt performance, is to note that LEGITIMIZE_RELOAD_ADDRESS does
> not get used when called via get_secondary_mem.  The following will fix
> that up, assuming that L_R_A can cope with a VOIDmode (don't know, don't
> care) memory mode:

You'd have to add this use of VOIDmode to the LEGITIMIZE_RELOAD_ADDRESS
documentation and go over all current definitions of
LEGITIMIZE_RELOAD_ADDRESS.

> Fifth, also wrt performance, is to note that the reload added by 
> L_R_A does not seem to get combined with identical reloads.  I.e.
> I get 

Combining reloads too early can raise the register pressure.
So for SMALL_REGISTER_CLASSES the preferred strategy is to keep distinct
reloads, but allocate them to the same register and then merge them 
in merge_assigned_reloads if that is still possible.

I have done most reload work for SMALL_REGISTER_CLASSES machines, so I
might have missed places where ! SMALL_REGISTER_CLASSES machines should
do reload merging.
On the other hand, we want to remove away from SMALL_REGISTER_CLASSES
in general.  The SMALL_REGISTER_CLASSSES targets really can't do without
the postponing of reload merging.  Moreover, now that register allocation has
been improved for cases where merges are possible -
reload_reg_free_for_value_p recognizes when the same value is loaded in
two reloads and thus allows to inherit that value for both reloads -
this strategy might also prove useful for ! SMALL_REGISTER_CLASSES targets.
So, as a first step,  you could just remove the conditionalization on
SMALL_REGISTER_CLASSES for the call to merge_assigned_reloads, i.e. do
the call unconditionally.