This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]


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

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

/* 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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]