In default_secondary_reload, we have this code:
if (reg_class_subset_p (reload_class, insn_class))
{
gcc_assert (scratch_class == class);
class = NREGS;
Why doesn't it allow the scratch class to be a superset of the desired
class? I'm trying to build am33_2.0-linux-gnu, and I'm getting to
here with scratch_class GENERAL_REGS and class DATAR_EXTENDED_REGS.
reload_class and insn_class are ADDRESS_REGS.

DJ Delorie <dj (AT) redhat (DOT) comwrites:

In default_secondary_reload, we have this code:

if (reg_class_subset_p (reload_class, insn_class))
{
gcc_assert (scratch_class == class);
class = NREGS;

Why doesn't it allow the scratch class to be a superset of the desired
class? I'm trying to build am33_2.0-linux-gnu, and I'm getting to
here with scratch_class GENERAL_REGS and class DATAR_EXTENDED_REGS.
reload_class and insn_class are ADDRESS_REGS.

In general the reload_in and reload_out instructions should match
SECNDARY_INPUT_RELAD_CLASS and SECNDARYUTPUT_RELAD_CLASS. It's
a sanity check. What reason is there to have scratch_class be
something else?

Ian

What reason is there to have scratch_class be something else?

SECNDARY_RELAD_CLASS has the option of limiting the reload class.
The mn10300 has a generic SImode reload_in that allows GENERAL_REGS,
but SECNDARY_RELAD_CLASS specifies a smaller class based on the
registers that need reloading.

The default hook for secondary_reload uses SECNDARY_RELAD_CLASS but
assumes it's going to return the same class as the pattern (in which
case, why bother defining it?). Since we're only allowed one reload
pattern per mode, this seems like an artificial limitation.

DJ Delorie <dj (AT) redhat (DOT) comwrites:

What reason is there to have scratch_class be something else?

SECNDARY_RELAD_CLASS has the option of limiting the reload class.
The mn10300 has a generic SImode reload_in that allows GENERAL_REGS,
but SECNDARY_RELAD_CLASS specifies a smaller class based on the
registers that need reloading.

The default hook for secondary_reload uses SECNDARY_RELAD_CLASS but
assumes it's going to return the same class as the pattern (in which
case, why bother defining it?). Since we're only allowed one reload
pattern per mode, this seems like an artificial limitation.

Well, first I should note that SECNDARY_RELAD_CLASS is now
considered to be the old way of doing things. Have you considered
switching to TARGET_SECNDARY_RELAD?

That said, while it makes sense to me that SECNDARY_RELAD_CLASS and
the reload_{in,out} instruction should be in synch was one of
the flaws of the old scheme, really can't think of anything that
would go wrong if class is a subset of scratch_class.

You should run any patch past Joern, though.

Ian

I'd hesitate to apply patches to default_secondary_reload.

Even if it's wrong?

If your port triggers any of the sanity checks, convert it to the
new infrastructure, as it provides a much better interface.

In my case, I'm just trying to get the am33 port to function, because
I have some patches I need to test. I don't currently have the
resources to do that kind of change, and there are a *lot* of ports
that still use the macros.

Ian Lance Taylor wrote:
You should run any patch past Joern, though.
I'd hesitate to apply patches to default_secondary_reload. If your port
triggers any of the sanity checks, convert it to the new infrastructure,
as it provides a much better interface.
Bernd