On Mon, Sep 3, 2012 at 6:12 PM, Marc Glisse <marc.gli...@inria.fr> wrote:
> 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?
Yes, if CCP sees
vec_1 = VEC_PERM <cst1, var, cst2>;
scalar_2 = BIT_FIELD_REF <vec_1, ....cst3>;
then if vec_1 ends up being constant it should figure out that vec_1 is constant
and that scalar_2 is constant. Of course if we have
vec_1 = VEC_PERM <cst1, var1, var2>;
and var1/var2 are CONSTRUCTORS with some elements constants then
it won't be able to do that and forwprop should do it. So I suppose handling
constants in forwprop is fine (but it would be nice to double-check if in
the first example CCP figures out that vec_1 and scalar_2 are constant).
> 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)
CCP should only do lattice-based constant propagation, other cases need
to be handled in forwprop.
>> 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
