Re: vect: Fix wrong shift_n after widening on BE [PR107338]

["Kewen.Lin" <linkw@linux.ibm.com>]

on 2022/10/24 20:55, Richard Biener wrote:
> On Mon, Oct 24, 2022 at 12:43 PM Kewen.Lin <linkw@linux.ibm.com> wrote:
>>
>> Hi,
>>
>> As PR107338 shows, with the use of widening loads, the
>> container_type can become a wider type, it causes us to
>> get wrong shift_n since the BIT_FIELD_REF offset actually
>> becomes bigger on BE.  Taking the case in PR107338 as
>> example, at the beginning the container type is short and
>> BIT_FIELD_REF offset is 8 and size is 4, with unpacking to
>> wider type int, the high 16 bits are zero, by viewing it
>> as type int, its offset actually becomes to 24.  So the
>> shift_n should be 4 (32 - 24 - 4) instead of 20 (32 - 8
>> - 4).
>>
>> I noticed that if we move shift_n calculation early
>> before the adjustments for widening loads (container type
>> change), it's based on all the stuffs of the original
>> container, the shfit_n calculated there is exactly what
>> we want, it can be independent of widening.  Besides, I
>> add prec adjustment together with the current adjustments
>> for widening loads, although prec's subsequent uses don't
>> require this change for now, since the container type gets
>> changed, we should keep the corresponding prec consistent.
>>
>> Bootstrapped and regtested on x86_64-redhat-linux,
>> aarch64-linux-gnu, powerpc64-linux-gnu P7 and P8 and
>> powerpc64le-linux-gnu P9 and P10.
>>
>> Is it ok for trunk?
> 
> OK.

Thanks Richi, committed in r13-3474.

BR,
Kewen