This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][RFC] Introduce BIT_FIELD_INSERT
- From: Richard Biener <rguenther at suse dot de>
- To: Eric Botcazou <ebotcazou at adacore dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 17 May 2016 09:50:43 +0200 (CEST)
- Subject: Re: [PATCH][RFC] Introduce BIT_FIELD_INSERT
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot LSU dot 2 dot 11 dot 1605131239490 dot 18037 at t29 dot fhfr dot qr> <1767442 dot te1Re9SKKQ at polaris>
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.