On Fri, May 10, 2019 at 9:25 AM Uros Bizjak <ubiz...@gmail.com> wrote: > > On Fri, May 10, 2019 at 9:10 AM Richard Biener > <richard.guent...@gmail.com> wrote: > > > > 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? > > I have removed support to STV shifts with dynamic count just because > of the issue you mentioned. It is not possible to substitute > truncating shift with a non-truncating one in STV, so there is IMO no > problem with the proposed idea. > > BTW: We do implement the removal of useless count argument masking > (for shifts and bit test insns) with several define_insn_and_split > patterns that allow combine to create compound insn (please grep for > "Avoid usless masking" in i386.md). However, the generic handling > would probably be more effective, since the implemented approach > doesn't remove masking in cases masked argument is used in several > shift instructions.
But that's more a combine limitation than a reason going for the "hidden" IL semantic change. But yes, if the and is used by non-masking insns then it's likely cheap enough to retain it. If the masking were always in place (combined with the shift if a suitable insn exists) then STV handling should be possible, it just would need to split the insn to do the masking and then the shift (of course that might not be very profitable). Richard. > Uros. > > > IMHO a recipie for desaster. > > > > Richard. > > > > > [1] https://www.felixcloutier.com/x86/bt > > > > > > Uros.
