Robin Dapp via Gcc-patches writes:
>> It's not just a question of which byte though. It's also a question
>> of which bit.
>>
>> One option would be to code-generate for even X and for odd X, and select
>> between them at runtime. But that doesn't scale well to 2+2X and 1+1X.
>>
>> Otherwise I
> It's not just a question of which byte though. It's also a question
> of which bit.
>
> One option would be to code-generate for even X and for odd X, and select
> between them at runtime. But that doesn't scale well to 2+2X and 1+1X.
>
> Otherwise I think we need to treat the bit position as
Robin Dapp writes:
>> But in the VLA case, doesn't it instead have precision 4+4X?
>> The problem then is that we can't tell at compile time which
>> byte that corresponds to. So...
>
> Yes 4 + 4x. I keep getting confused with poly modes :)
> In this case we want to extract the bitnum [3 4] = 3
> But in the VLA case, doesn't it instead have precision 4+4X?
> The problem then is that we can't tell at compile time which
> byte that corresponds to. So...
Yes 4 + 4x. I keep getting confused with poly modes :)
In this case we want to extract the bitnum [3 4] = 3 + 4x which
would be in byte
[Sorry for any weird MUA issues, don't have access to my usual set-up.]
> when looking at a riscv ICE in vect-live-6.c I noticed that we
> assume that the variable part (coeffs[1] * x1) of the to-be-extracted
> bit number in extract_bit_field_1 is a multiple of BITS_PER_UNIT.
>
> This means that b
