https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118206
--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
One more thing.
All or most of the uniform_integer_cst_p in the new code look
weird/unexpected/wrong.
uniform_integer_cst_p skips location wrappers and then accepts either an
INTEGER_CST or vectors which repeat the same constant, tons of different trees.
So,
&& uniform_integer_cst_p (res_ops[1]))
{
loc[1] = gimple_location (SSA_NAME_DEF_STMT (exp));
exp = res_ops[0];
and_mask = wi::to_wide (res_ops[1]);
doesn't really guarantee wi::to_wide won't ICE, which is only when res_ops[1]
is INTEGER_CST, so I think here it should use && TREE_CODE (res_ops[1]) ==
INTEGER_CST)
instead.
The second spot, dunno, but maybe later on the xor stuff will rely on
INTEGER_CST.
&& uniform_integer_cst_p (res_ops[1]))
{
loc[2] = gimple_location (SSA_NAME_DEF_STMT (exp));
exp = res_ops[0];
if (!tree_fits_shwi_p (res_ops[1]))
return NULL_TREE;
shiftrt = tree_to_shwi (res_ops[1]);
here the uniform_integer_cst_p (res_ops[1]) check is just a waste of time, the
tree_fits_shwi_p check will punt whenever it isn't INTEGER_CST. So maybe
better just use the tree_fits_shwi_p check to the first if?
&& uniform_integer_cst_p (lr_arg)
&& wi::popcount (wi::to_wide (lr_arg)) == 1)
Again, this will ICE whenever lr_arg isn't INTEGER_CST, which
uniform_integer_cst_p doesn't guarantee. 3 times similarly after that.
if (TYPE_SIZE (TREE_TYPE (ll_inner))
&& uniform_integer_cst_p (TYPE_SIZE (TREE_TYPE (ll_inner))))
ll_end_region = tree_to_poly_uint64 (TYPE_SIZE (TREE_TYPE (ll_inner)));
tree_to_poly_uint64 will ICE if not tree_fits_poly_uint64_p, so I think that
predicate should be used instead of uniform_integer_cst_p. Once more later.
