>> 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.
>
> But IL semantic differences based on mode is even worse. What happens
> if STV then substitues a vector register/op but you previously optimized
> with the assumption the count would be truncated since the shift was SImode?
>
> IMHO a recipie for desaster.
Would a shift_truncation_mask (rtx op, machine_mode mode) as replacement
for SHIFT_COUNT_TRUNCATED and the old hook make more sense than just
relying on the mode? That would be a way to alleviate the first counter
argument to SHIFT_COUNT_TRUNCATED ("not flexible enough"). Richard's
argument about the premature optimization however, I can agree on and I
don't see a way to avoid this. Doesn't it apply to other middle-end
optimizations as well, though, and is handled via additional flags that
prohibit selected follow-up optimizations?
The problem with my proposed unifying is that the hook is/will be called
by RTL as well as tree passes and would need to have an argument type
that can hold all of their respective shift-like operations in order to
return a useful mask. My local version uses an rtx that only contains
an rtx_code which is filled in an ad-hoc fashion for the tree passes.
That said, I don't intend to pursue the proposal given the opinions so
far - after all it would only save a few lines in our backend and some
others. I would find it useful to more clearly document the current
methods as deprecated since they are apparently not useful for any of
the major targets.
Regards
Robin
