On Fri, May 10, 2019 at 4:35 PM Segher Boessenkool <seg...@kernel.crashing.org> wrote: > > On Fri, May 10, 2019 at 09:42:47AM +0200, Richard Biener wrote: > > On Fri, May 10, 2019 at 9:25 AM Uros Bizjak <ubiz...@gmail.com> wrote: > > > > 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? > > What is STV?
scalar-to-vector pass for x86 targets that uses vector instructions and XMM registers to perform DImode instructions. Uros. > > 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). > > Why does the pattern with masking split? It could just be a define_insn. > Combine will try to get rid of the masking, to simplify the RTL. Going in the > other direction is probably not profitable :-/ > > > Segher
