This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit targets
- From: Richard Henderson <rth at redhat dot com>
- To: Richard Sandiford <rsandifo at redhat dot com>
- Cc: "Maciej W. Rozycki" <macro at linux-mips dot org>, Nigel Stephens <nigel at mips dot com>, gcc-patches at gcc dot gnu dot org, linux-mips at linux-mips dot org
- Date: Fri, 3 Sep 2004 00:20:10 -0700
- Subject: Re: [patch] MIPS/gcc: Revert removal of DImode shifts for 32-bit targets
- References: <Pine.LNX.4.58L.0408042123030.31930@blysk.ds.pg.gda.pl> <87r7qiwz54.fsf@redhat.com> <20040809220838.GE16493@redhat.com> <87zn5336h7.fsf@redhat.com> <20040810232020.GA21922@redhat.com> <87eklnw0g7.fsf@redhat.com> <20040903065331.GG20559@redhat.com> <87sm9zg7dg.fsf@redhat.com> <20040903070858.GA24082@redhat.com> <87oekng72k.fsf@redhat.com>
On Fri, Sep 03, 2004 at 08:11:47AM +0100, Richard Sandiford wrote:
> But the point as I understand it is that the generic optimisers
> (e.g. simplify-rtx.c) can't tell the difference between an ASHIFT
> that came from an (ashift ...) in the instruction stream or from
> something that was generated artificially by expand_compound_operation.
That would be a bug in expand_compound_operation, I would think.
The alternative is to not add your new hook and do what you can
with the existing SHIFT_COUNT_TRUNCATED macro. Which I recommend
that you do; I don't think you really want to have the shift bits
dependent on a cleanup / infrastructure change of this scale.
r~