Richard Henderson <rth@xxxxxxxxxx> writes:
> 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.
FWIW, that's what my original patch did:
http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00461.html
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
But because it depended on S_C_T, the original patch produced much
worse code for ARM than the new one does.
Is the new target hook really that invasive? It doesn't affect any
other code as such.
The only change not directly related to the optabs expansion was the
simplify-rtx.c thing, and like I said in my covering message, I think
that code's bogus anyway:
This seems pretty dubious anyway. What if a define_expand in the backend
uses shifts to implement a complex named pattern? I'd have thought the
backend would be free to use target-specific knowledge about what that
shift does with out-of-range values. And if we are later able to
constant-fold the result, the code above might not do what the
target machine would do.
To be honest, I'd still like to apply that hunk even if we go back to S_C_T.
Richard
