http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50918
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |irar at gcc dot gnu.org,
| |jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-11-01
14:18:47 UTC ---
I don't see that for long long we would create inefficient shifts, at least not
with -mavx2.
For the char/short shifts, I guess we'd want to add
vect_recog_narrow_shift_pattern that would recognize these.
For shifts by constant, I think it can be done always (if the constant is
bigger
than precision of the narrower type for left shifts and right unsigned shifts
we can just change it into clearing the destination (though the earlier
optimizers should have done that already), for right arithmetic shift
we could do x < 0 ? -1 : 0), for shifts by variable we'd need a target hook or
macro how vector shifts with larger or equal shift count than precision behave.
AFAIK i?86 (all vector shifts) DTRT for this (i.e. left/right unsigned shifts
for too big count store zero and right arithmetic shift stores copies of the
sign bit everywhere), but e.g. Altivec shifts truncate and thus can't be used.
