On 7/31/23 08:01, Richard Biener via Gcc-patches wrote:
The following makes sure to limit the shift operand when vectorizing
(short)((int)x >> 31) via (short)x >> 31 as the out of bounds shift
operand otherwise invokes undefined behavior. When we determine
whether we can demote the operand we know we at most shift in the
sign bit so we can adjust the shift amount.
Note this has the possibility of un-CSEing common shift operands
as there's no good way to share pattern stmts between patterns.
We'd have to separately pattern recognize the definition.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Not sure about LSHIFT_EXPR, it probably has the same issue but
the fallback optimistic zero for out-of-range shifts is at least
"corrrect". Not sure we ever try to demote rotates (probably not).
OK?
Thanks,
Richard.
PR tree-optimization/110838
* tree-vect-patterns.cc (vect_recog_over_widening_pattern):
Adjust the shift operand of RSHIFT_EXPRs.
* gcc.dg/torture/pr110838.c: New testcase.
I'm not a fan of the asymmetric handling across RSHIFT/LSHIFT. But if
you think the asymmetry isn't a problem in practice, then I won't object.
Jeff
