Yvan Roux <yvan.r...@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
