Re: RFC/RFA: patch for PR 22156: improve SRA for bit-fields

[Alexandre Oliva <aoliva at redhat dot com>]

On Mar 19, 2007, Eric Botcazou <ebotcazou@adacore.com> wrote:

>> This patch is intended to group fields that aren't accessed directly
>> into larger variables that can then be copied as a unit.

> You seem to be reusing the grouping mechanism implemented for ARRAY_RANGE_REF:

Not really.  I'm just reusing that flag to mean something else in
combination with in_bitfld_block.  I should probably have used a
separate flag, but I started out misunderstanding how groups worked,
and then, when I noticed I was looking for something entirely
different, I had already started using the same flag.  I can change it
if it bothers you.

> so the new kind of group is not really a group according to the definition

>   /* True if this element is a group of members of its parent.  */
>   bool is_group;

It is.  And, to me, it is even more so than the current definition.

> Can't we come up with a unified implementation for groups?

We might, but the two concepts serve very different purposes.

ARRAY_RANGE_REFs are alternate non-preferred means to access certain
portions of an element, and there may be multiple overlapping groups
referring to the same fields, depending on the references that are
present in the program.

BIT_FIELD_REFs are preferred means to access certain portions of an
element, and there may not be multiple overlapping portions referring
to the same fields; the group actually aggregates fields that are not
explicitly referenced in the program.

So I fail to see the point of trying to unify them.  There could be
some point in permitting BIT_FIELD_REF groups along the lines of
ARRAY_RANGE_REFs, for copies between data structures that had
different fields scalarized but that could still benefit from copying
multiple grouped (should I say blocked?) bit-fields from one
representation to the other.  This could be done an add-on.

Or I could try to force the BIT_FIELD_REF stuff to fit in the existing
group machinery, but this seems highly inappropriate.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}