Re: RFA: reload infrastructure to fix PR target/21623

[Ian Lance Taylor <ian at airs dot com>]

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

> >I actually don't like changing the target hook in OVERRIDE_OPTIONS,
> >because I would prefer that targetm be a const variable.  But I know
> >that targets do this today for various reasons, e.g., ARM for
> >rtx_costs.  But that is a minor detail--for example, it's easy enough
> >to have the single function call through a function pointer.
> >
> But these extra indirections cost more processing time.  What do you gain
> making targetm const?

The possibility of faster code when compiling with -combine, as it
becomes possible to inline the target functions.  I admit this is a
long-term possibility.

> >Or, even simpler, have default_emit_secondary_reload insist on having
> >a single scratch [sic (1)] register, and emit instructions to copy from FROM to
> >the scratch register, and then from the scratch register to TO.
> >
> No, that is completely besides the point.  You can use the default function
> only when there is no secondary reload that needs to be handled in a
> non-default
> way.

I'm not sure how that differs from what I said.

> You could call this default function from your hook, but you'd have to
> decide first if you should do that.  That means duplicating decision
> logic from
> the time when you select the reload classes.
> Indeed, it could make sense not to have a target hook for the insn
> emitting at all,
> but have the regclass calculating code set a function pointer for that.
> We could have more than one, so that separate steps can be described with
> separate functions - which might even be gen_* function generated by the md
> file.  This might me interwoven with the dependency information.  E.g. we
> could specify that the value in a particular scratch register is to be
> calculated
> by using the addsi_mark3 expander with two specified inputs.  The
> calculation
> of the scratch register is then dependent on these two inputs.
> Using separate patterns for separate steps can not only make it easier
> to break up
> the task and reuse already existing expanders, it is also necessary in
> order to
> elide steps that become unnecessary because of reload inheritance.
> So, each of these expansions has a function pointer to call, a number of
> values that it sets, and likely / possibly some inputs and/or internal
> scratch
> registers.  A possible refinement here is also that where convenient,
> information about the number and kind of operands can be specified with an
> instruction name, and translated into the appropriate assignments with some
> gen* magic.

I think that what you are talking about at this point amounts to
writing the instructions which do the reload.  Perhaps it would make
sense to produce a sequence of insns, plus a list of required
registers.  For each required register we would point to the insn
which set it and the insn(s) which used it (plus the location(s)
within each insn where it is used).  We could explicitly represent the
value that the register will have, for reload inheritance.  The
dependencies are described by the insn list.  The final insn in the
sequence would set the register being reloaded, or the memory location
to which the register is being stored.

The possible drawback I see here is that you might want to emit
different insns depending on the particular register that reload
chooses.  That could be handled in principle by using insn
altenatives.  I'm not sure if it would be otherwise problematical.

Ian