On Mon, 3 Sep 2012, Richard Guenther wrote:
+ if (code == VEC_PERM_EXPR)
+ {
+ tree p, m, index, tem;
+ unsigned nelts;
+ m = gimple_assign_rhs3 (def_stmt);
+ if (TREE_CODE (m) != VECTOR_CST)
+ return false;
+ nelts = VECTOR_CST_NELTS (m);
+ idx = TREE_INT_CST_LOW (VECTOR_CST_ELT (m, idx));
+ idx %= 2 * nelts;
+ if (idx < nelts)
+ {
+ p = gimple_assign_rhs1 (def_stmt);
+ }
+ else
+ {
+ p = gimple_assign_rhs2 (def_stmt);
+ idx -= nelts;
+ }
+ index = build_int_cst (TREE_TYPE (TREE_TYPE (m)), idx * size);
+ tem = fold_build3 (BIT_FIELD_REF, TREE_TYPE (op), p, op1, index);
This shouldn't simplify, so you can use build3 instead.
I think that it is possible for p to be a VECTOR_CST, if the shuffle
involves one constant and one non-constant vectors, no?
Well, constant propagation should have handled it ...
When it sees __builtin_shuffle(cst1,var,cst2)[cst3], CCP should basically
do the same thing I am doing here, in the hope that the element will be
part of cst1 instead of var? What if builtin_shuffle takes 2 constructors,
one of which contains at least one constant? It looks easier to handle it
here and let the next run of CCP notice the simplified expression. Or do
you mean I should add the new function to CCP (or even fold) instead of
forwprop? (wouldn't be the first time CCP does more than constant
propagation)
If you use fold_build3 you need to check that the result is in expected form
(a is_gimple_invariant or an SSA_NAME).
Now that I look at this line, I wonder if I am missing some unshare_expr for
p and/or op1.
If either is a CONSTRUCTOR and its def stmt is not removed and it survives
into tem then yes ...
But the integer_cst doesn't need it. Ok, thanks.
--
Marc Glisse
