This is the mail archive of the gcc@gcc.gnu.org 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]

BIT_FIELD_REF on the LHS


So I started to try to fold *(type*)(&vector_type_var) into
BIT_FIELD_REF <t, 32, 0> but I ran into a bug where the SSA messes
itself up.
This works for the right hand side just fine as
BIT_FIELD_REF<SSA_NAME, x, y > is easyly valid gimple.  When the
BIT_FIELD_REF is on the left hand side, it turns out that we produce:
BIT_FIELD_REF<t1_2, x, y > = t_1 still even though t1_2 is killed
during the BIT_FIELD_REF.
I don't see anything in either tree.def or tree-ssa.texi which would
cause the orginal non-gimplified tree to be invalid.  So my question
is should we document that BIT_FIELD_REF on the lhs for a SSA_NAME
invalid gimple?

I just looked into the mainline and saw that we actually produce a
checking internal error
while processing this case:
t.c: In function 'f':
t.c:4: error: GIMPLE register modified with BIT_FIELD_REF
BIT_FIELD_REF <tD.1514_6, 32, 0> = t1D.1516_1;

This is not right after into SSA though but right after the alias pass
which seems to me
that the variable should not be marked for a register.

Does anyone have an idea how to get either the aliasing pass not to
mark t for a register or the name and semantics for a tree code which
sets one part of a vector and returns a new vector?

Yes we could produce v = { v[0], v[1], other, v[3] }; but that seems a
bit harder to understand and produce good code from as the expanders
are not so good.

Thanks,
Andrew Pinski

PS http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02150.html added the
ability for having BIT_FIELD_REF on the LHS.


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