RFA: reload infrastructure to fix PR target/21623

[Ian Lance Taylor]

Joern RENNECKE <joern.rennecke@st.com> writes:

> While the register-class related problems could be solved with processing
> mutliple alternatives, that would not solve the problems with mode
> mismatches, not the need to lump together completely unrelated
> patterns for different subtargets.  Therefore, I think we need the ability
> to have multiple reload patterns, and match them more specifically.
> I first though using an _foo suffix, but there are already some patterns
> with such names, and it also could cause confusion with cc_foo modes.
> I therefore choose __foo suffixes; no patterns that match this exist at the
> moment in the FSF sources.

SECONDARY_{,INPUT_,OUTPUT_}RELOAD_CLASS and reload_{in,out} are
already incredibly confusing.  I don't think that adding another
confusing feature on top of them is the right way to go.

With our current infrastructure, I can't think of any benefit to the
reload_in and reload_out patterns at all.  They've been around for a
long time, at least since gcc 1.23, and maybe they once made sense.
But now they are always implemented using define_expand.  The
constraints are mainly used in a strange combination with the
SECONDARY_RELOAD_CLASS macros to determine how many and which types of
scratch registers are required.

If we're going to tackle this at all, I think we should simplify it.
For example, suppose we add a new target hook

int TARGET_SECONDARY_RELOAD (enum reg_class, enum machine_mode,
                             rtx x, bool in, enum reg_class *classes)

Like today, if IN is true we are copying X to a register in CLASS with
MODE, and otherwise we are copying a register in CLASS with MODE to X.
The function returns the number of scratch registers needed, and
stores the required classes in *CLASSES.  We use this information in
push_secondary_reload.  We can say that the maximum is two scratch
registers for now, and we can increase that without changing the
interface if some target ever needs more (which I hope is unlikely).

Then we add a corresponding target hook to emit the instructions:

void TARGET_EMIT_SECONDARY_RELOAD (rtx to, rtx from, rtx *scratch)

This is copying a value from FROM to TO.  The hook will only be called
if TARGET_SECONDARY_RELOAD returned non-zero.  SCRATCH will be an
array of the registers allocated by the reload pass.  They will have
the classes requested by TARGET_SECONDARY_RELOAD.  This hook must
ensure that any insns that it emits do not themselves require
reloading.

To me this seems a lot simpler than trying to remember what the
register constraints mean in the reload_{in,out} patterns.  And it
seems to give us the flexibility that you want.


This is probably not stage 3 material, but I don't think your patch is
really stage 3 material either.  Is there any temporary patch which
can fix the problem at hand for the 4.1 release, perhaps at the cost
of generating worse code?

Ian