Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit targets

[Richard Sandiford <rsandifo@redhat.com>]

Richard Henderson <rth@redhat.com> writes:
> On Fri, Sep 03, 2004 at 08:29:39AM +0100, Richard Sandiford wrote:
>> The patch I posted this week was in response to the request for
>> wider-ranging target support:
>> 
>>     http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00606.html
>
> Ah.  I wasn't actually asking for wider target support.  I was 
> commenting that if we wanted something better, we'd have to add
> new target support.

Ooops!  I misunderstood, sorry.

>> Is the new target hook really that invasive?  It doesn't affect any
>> other code as such.
>
> No... I guess not.  And it is a start if we ever do decide to
> expand its meaning to replace S_C_T.
[...]
> Ok, revised patch approved.

Thanks, applied.

Looking back, I see I didn't do a very good job of explaining why
I think S_C_T and this target hook are doing two different things.
A bit more explanation (mostly for the record, since I doubt I'm
saying anything surprising here):

I can only see two optimisations guarded by !S_C_T, both of them in
combine.c.  They only disallow S_C_T because we might have already
optimised the construct in a different way.  All other uses of S_C_T
are used for shifts.

So the important point is that: although S_C_T requires a particular
behaviour for things like ZERO_EXTRACT, it is never actually used in
a positive context for ZERO_EXTRACT rtxes.  S_C_T is only ever used
in a positive context for shift rtxes.

As I understand it, the reason that S_C_T has those extra requirements
is that we have no way of tracking where a particular shift came from.
Sometimes it might come from an insn's PATTERN, sometimes it might be
the result of some temporary rewrites, such as that performed by combine.c
for "compound" operations.  The definition of S_C_T says that these
rewrites must be valid.


It sounds like you're saying that the target hook should eventually
be extended to cover shift rtxes rather than shift optabs, and that
anything which generates a shift rtx should make sure the rtx behaves
correctly wrt these hooks.  So, for example, the onus for verifying the
ZERO_EXTRACT rewrites should be with combine rather than the backend.
Is that right?  If so, I'll try to look at that in the 3.6 timeframe.

Richard