BIT_FIELD_REF on the LHS

[Richard Guenther]

On 7/13/06, Andrew Pinski <pinskia@gmail.com> 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.
>