patch to fix SH4 mode-switching problems

Joern Rennecke amylaar@cygnus.co.uk
Mon Feb 7 11:12:00 GMT 2000


> In optimize_mode_switching we search for uses of the return value.  Is that
> code still needed?

I'm not sure.  There used to be code that really needed the use of the
return value to be adjacent with the return insn, but a lot of the USE
uses have been removed recently.  Some target port might still have
ideas how the USEs are arranged, but that should be a non-issue since that
can be checked at the time a port is changed to take advantage of the
OPTIMIZE_MODE_SWITCHING facility.
However, if we ever want to release a 2.9.5.x version with a working SH
port, that it'll need the loop that searches for the USE of the return
value.

> What is the point behind checking e->aux?  If it's just to avoid losing
> the head of the edge is the entry block, then we should just check for that
> directly.

All the insertion sites are marked with e->aux != 0.
This is actually explained in the comment in front of make_preds_opaque.

>   > +   if (GET_CODE (reg) == SUBREG)
>   > +     reg = SUBREG_REG (reg);
> Shouldn't this be a while loop?  Do we need similar code in reg_dies?

No, SUBREG is not allowed to nest.
The check for SUBREGs is a correctnes issue in reg_becomes_live, but
only an optimization issue in reg_dies - unless we run out of registers
to use.

> You can either describe it at a high level, or use the SH stuff as an
> example.

Like this?

...
@item OPTIMIZE_MODE_SWITCHING (@var{entity})
Define this macro if the port needs extra instructions inserted for mode
switching in an optimizing compilation.
For an example, look at the SH port.
You can have multiple entities that are mode-switched, and select at run time
...


More information about the Gcc-patches mailing list