>> Event SHIFT_COUNT_TRUNCATED is no perfect match to what our hardware
>> does because we always only consider the last 6 bits of a shift operand.>
>> Despite all the warnings in the other backends, most notably
>> SHIFT_COUNT_TRUNCATED being "discouraged" as mentioned in riscv.h, I
>> wrote the attached tentative patch. It's a little ad-hoc, uses the
>> SHIFT_COUNT_TRUNCATED paths only if shift_truncation_mask () != 0 and,
>> instead of truncating via & (GET_MODE_BITSIZE (mode) - 1), it applies
>> the mask returned by shift_truncation_mask. Doing so, usage of both
>> "methods" actually reduces to a single way.
> THe main reason it's discouraged is because some targets have insns
> where the count would be truncated and others where it would not. So
> for example normal shifts might truncate, but vector shifts might or
> (mips) or shifts might truncate but bit tests do not (x86).
Bit tests on x86 also truncate [1], if the bit base operand specifies
a register, and we don't use BT with a memory location as a bit base.
I don't know what is referred with "(real or pretended) bit field
operations" in the documentation for SHIFT_COUNT_TRUNCATED:
However, on some machines, such as the 80386 and the 680x0,
truncation only applies to shift operations and not the (real or
pretended) bit-field operations. Define 'SHIFT_COUNT_TRUNCATED' to
Vector shifts don't truncate on x86, so x86 probably shares the same
destiny with MIPS. Maybe a machine mode argument could be passed to
SHIFT_COUNT_TRUNCATED to distinguish modes that truncate from modes
that don't.
[1] https://www.felixcloutier.com/x86/bt
Uros.
