Re: [PATCH][RFC] Introduce BIT_FIELD_INSERT

[Eric Botcazou <ebotcazou@adacore.com>]

> The following patch adds BIT_FIELD_INSERT, an operation to
> facilitate doing bitfield inserts on registers (as opposed
> to currently where we'd have a BIT_FIELD_REF store).

Why not call it BIT_FIELD_INSERT_EXPR instead to make it clear that it's an 
expression and not a mere operation?

> Originally this was developed as part of bitfield lowering
> where bitfield stores were lowered into read-modify-write
> cycles and the modify part, instead of doing shifting and masking,
> be kept in a more high-level form to ease combining them.
> 
> A second use case (the above is still valid) is vector element
> inserts which we currently can only do via memory or
> by extracting all components and re-building the vector using
> a CONSTRUCTOR.  For this second use case I added code
> re-writing the BIT_FIELD_REF stores the C family FEs produce
> into BIT_FIELD_INSERT when update-address-taken can otherwise
> re-write a decl into SSA form (the testcase shows we miss
> a similar opportunity with the MEM_REF form of a vector insert,
> I plan to fix that for the final submission).

The description in tree.def looks off then, it only mentions words and 
integral types.

> One speciality of BIT_FIELD_INSERT as opposed to BIT_FIELD_REF
> is that the size of the insertion is given implicitely via the
> type size/precision of the value to insert.  That avoids
> introducing ways to have quaternary ops in folding and GIMPLE stmts.

Yes, it's a bit unfortunate, but sensible.  Maybe add a ??? note about that.

-- 
Eric Botcazou