On Thu, Jul 18, 2019 at 09:01:13AM +0200, Jakub Jelinek wrote: > On Wed, Jul 17, 2019 at 12:00:32PM -0500, Segher Boessenkool wrote: > > I think we can say that *all* targets behave like SHIFT_COUNT_TRUNCATED > > for rotates? Not all immediates are valid of course, but that is a > > separate issue. > > Well, we'd need to double check all the hw rotate instructions on all the > targets to be sure.
Yes :-( > As for the current GCC code, SHIFT_COUNT_TRUNCATED value is used even for > rotates at least in combine.c, expmed.c and simplify-rtx.c and in > optabs.c through targetm.shift_truncation_mask, but e.g. in cse.c is used > only for shifts and not rotates. Many targets cannot use SHIFT_COUNT_TRUNCATED, and not even targetm.shift_truncation_mask, because the actual mask depends on the insn used, or rtl code used at least, not just the mode. [snip] > hunk in there, just it is limited to scalar rotates ATM rather than vector > ones through is_int_mode. So I bet the problem with the vector shifts is > just that > tree-vect-generic.c support isn't there. :-) Should we always allow both directions in gimple, and pretend both are cheap? Should we allow only one direction, and let the target select which, or both? Segher
