BIT_FIELD_REF on the LHS

[Paolo Bonzini]

Diego Novillo wrote:
> Andrew Pinski wrote on 07/13/06 08:37:
> 
>> #define vector __attribute__((vector_size(16) ))
>>
>> vector float f(vector float t, vector t1)
>> {
>>   return t/t1;
>> }
>>
>> -- Pinski
>>
> That definitely seems wrong.  We shouldn't be considering vector types
> to be GIMPLE register types if we are going to be chunking them out with
> BIT_FIELD_REF.

Andrew's example currently chunks out t, using BIT_FIELD_REF on the RHS. 
  The returned value is then built with a CONSTRUCTOR.

> Allowing SSA names to be accessed in a non-atomic fashion is a recipe
> for bad codegen.

Only writing them, IIUC.  Reading should be ok.

This patch is sufficient for BIT_FIELD_REF on the LHS to be marked 
correctly as addressable:

Index: ../../gcc/tree-ssa-operands.c
===================================================================
--- ../../gcc/tree-ssa-operands.c       (revision 115364)
+++ ../../gcc/tree-ssa-operands.c       (working copy)
@@ -2006,6 +2006,8 @@ get_expr_operands (tree stmt, tree *expr

      case BIT_FIELD_REF:
        /* Stores using BIT_FIELD_REF are always preserving definitions.  */
+      if (flags & opf_is_def)
+       add_to_addressable_set (TREE_OPERAND (expr, 0), 
&s_ann->addresses_taken);
        flags &= ~opf_kill_def;

        /* Fallthru  */


GCC will then happily use VOPS for that variable:

   vector float f(vector float t, float t1)
   {
     *(float*)&t = t1;
    return t;
   }

has this .uncprop dump:

   f (t, t1)
   {
     vector float D.1522;

     #   t_3 = V_MAY_DEF <t_2>;
     BIT_FIELD_REF <t, 32, 0> = t1_1;
     #   VUSE <t_3>;
     D.1522_4 = t;
     return D.1522_4;
   }

But if you say this is dangerous, yes, I agree that the best thing to do 
is to treat VECTOR_TYPEs like COMPLEX_TYPEs and use 
DECL_COMPLEX_GIMPLE_REG_P.  Does COMPOSITE_TYPE_P, and 
DECL_COMPOSITE_GIMPLE_REG_P sound good as names?

Paolo