On 7/13/06, Andrew Pinski <[EMAIL PROTECTED]> wrote:
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.
it's only a partial kill, which you cannot do to ssa names. So you'd need to
go the
t1_2 = { t[0], other, t[1], t[2] }
route to fix this.
Richard.
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.
