The secondary reload
Ian Lance Taylor
Tue Dec 7 14:30:00 GMT 2010
firstname.lastname@example.org (Paulo J. Matos) writes:
> This happens on a really nasty set of rules that involve expands, splits
> and a TARGET_SECONDARY_RELOAD. Since this code has been brough through
> some older GCC versions, I am trying to get around to refactor it and
> hopefully in the end, get rid of the register spill failure.
> So, I would like if someone could give a couple of hints on how the
> splits fit together with the rest.
> So, at expansion time we generate the RTL and during register allocation
> and reload we have loads of matching. However, what happens when we have
> a define_insn where the output template is "#". Will this trigger the
> split at expansion time too?
Splits don't happen at expansion time. They happen later during the
processing. Splits happen before register allocation, and then again
after register allocation. After the second split, no output template
should still be "#".
> During reload we have TARGET_SECONDARY_RELOAD being massively called
> with all kinds of expressions and reload modes. One interesting thing I
> noticed is that in gcc4.3 i386 has no TARGET_SECONDARY_RELOAD defined
> and it made me wonder if the secondary reload is really something of a
> hack that is best avoided by writing clearer/better backend rules or if
> there are specific cases which it _has_ to be defined for reload to
There are cases where a processor needs a secondary reload. You need it
when you can not move between registers of two classes in a single
instruction, and you need it when you can't load and store registers of
any class directly to/from memory.
More information about the Gcc