Re: RFC: patch to build GCC for arm with LRA

[Richard Sandiford <rdsandiford at googlemail dot com>]

Yvan Roux <yvan.roux@linaro.org> writes:
>> Yeah, but that's because strip_address_mutations doesn't consider
>> SIGN_EXTRACT to be a "mutation" as things stand.  My point was that
>> I think it should, at least for the special extract-from-lsb case.
>> It then shouldn't be necessary to handle SIGN_EXTRACT in the other
>> address-analysis routines.
>>
>> (That might be what you meant, sorry, just thought I'd say in case.)
>
> You did well.  I wanted to handle it in strip_address_mutation, but
> misread the code and thought that it wasn't called all the time, but
> in any case I didn't thought to the endianness issue. I've added
> ZERO_EXTRACT too in this treatment, but wonder if for the big endian
> case the third operand has to be taken into account, like this:
>
> GET_MODE_PRECISION(mode) - size - pos

Endianness in the BYTES_BIG_ENDIAN sense shouldn't be a problem AFAIK.
We just need to worry about BITS_BIG_ENDIAN.  For:

  ({sign,zero}_extract:m X len pos)

"pos" counts from the lsb if !BITS_BIG_ENDIAN and from the msb if
BITS_BIG_ENDIAN.  So I think the condition should be something like:

  pos == (BITS_BIG_ENDIAN ? GET_MODE_PRECISION (m) - len : 0)

Agreed that it makes sense to handle ZERO_EXTRACT in the same way.

Thanks,
counts