This is the mail archive of the
mailing list for the GCC project.
Re: BIT_FIELD_REF on the LHS
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)
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:
--- ../../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),
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;
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;
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?