https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117927
--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #3)
> So
> --- gcc/match.pd.jj 2024-12-05 18:29:46.246399098 +0100
> +++ gcc/match.pd 2024-12-06 09:38:35.670473040 +0100
> @@ -4981,7 +4981,8 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> orotate (rrotate lrotate)
> (simplify
> (rotate @0 (minus INTEGER_CST@1 @2))
> - (if (element_precision (TREE_TYPE (@0)) == wi::to_wide (@1))
> + (if (element_precision (TREE_TYPE (@0)) == wi::to_wide (@1)
> + && tree_expr_nonzero_p (@2))
> (orotate @0 @2))))
>
> /* Turn (a OP c1) OP c2 into a OP (c1+c2). */
> plus adjust the testcase?
No because @2 being 0 is not an issue because we had `rotate(a, 32-0)` which is
undefined. Rather if @2 was 32 then it becomes undefined. That is 32-32 is 0
but after the referenced commit, 32 passes through.
This works:
`wi::leu_p (tree_nonzero_bits (@2), element_precision (TREE_TYPE (@0)) - 1)`
or
doing
(orotate @0 (bit_and @2 { build_cst_int (TREE_TYPE (@2), element_precision
(TREE_TYPE (@0)) - 1); }))
That is doing `orotate(@0, @2 & mask)`. I am leaning towards the and.
Also note we should be able to simplify `rotate(a, (-b)&mask)` to `orotate(a,
b&mask)` too which I will handle in a follow up patch too.
