Re: [PATCH][RFC] Introduce BIT_FIELD_INSERT

[Richard Biener <rguenther@suse.de>]

On Mon, 16 May 2016, Eric Botcazou wrote:

> > 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?

Had it like that first but it was so long ... ;)  Originally
I called it BIT_FIELD_EXPR but that's a bit ambiguous (with
BIT_FIELD_REF).

I'm fine with renaming it to BIT_FIELD_INSERT_EXPR, maybe
BIT_INSERT_EXPR then as it doesn't really have anything to do
with "bitfields".

Any preference?

> > 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.

I'll fix that up.

> > 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.

Ok.

Thanks,
Richard.