On Fri, May 10, 2019 at 12:44 AM Uros Bizjak <ubiz...@gmail.com> wrote: > > >> 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.
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. Richard. > [1] https://www.felixcloutier.com/x86/bt > > Uros.
