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
