combine BIT_FIELD_REF and VEC_PERM_EXPR

Marc Glisse marc.glisse@inria.fr
Mon Sep 3 13:39:00 GMT 2012


On Mon, 3 Sep 2012, Richard Guenther wrote:

> Please do the early outs where you compute the arguments.  Thus, right 
> after getting op0 in this case or right after computing n for the n != 1 
> check.

Ok.

> I think you need to verify that the type of 'op' is actually the element type
> of op0.  The BIT_FIELD_REF can happily access elements two and three
> of { 1, 2, 3, 4 } as a long for example.

Indeed I missed that.

> See the BIT_FIELD_REF foldings in fold-const.c.

That's what I was looking at (picked the same variable names size, idx, n) 
but I forgot that test :-(

>> +  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?

Now that I look at this line, I wonder if I am missing some unshare_expr 
for p and/or op1.

> Please also add handling of code == CONSTRUCTOR.

The cases I tried were already handled by fre1. I can add code for 
constructor, but I'll need to look for a testcase first. Can that go to a 
different patch?

-- 
Marc Glisse



More information about the Gcc-patches mailing list