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

[Alexandre Oliva <aoliva at redhat dot com>]

Sorry about the delay, I've been away, completely off-line, for the
past couple of days.

On Apr 16, 2007, "Andrew Pinski" <pinskia@gmail.com> wrote:

> SR.32D.2339_34 = SR.12D.2319_33(D) & 0x0fff0000000000000;

> in the early SRA.

> See how SR.12D.2319_33(D) is the default SSA name, that is the bug.

I don't quite see why this would be a bug.

main's tmp variable is initialized from the return value of sub.
Since sub's tmp scalarized, we can't implement this as a block copy.
This means we initialize each field separately.

But then, we've scalarized main's tmp to a single 64-bit integer
variable so, in order to assign to the bit-fields in it, we have to
explicitly preserve the other bits we don't touch.

That's what the & above does.  The only way we could avoid it would be
to somehow know that we're doing an initialization or a full copy,
rather than a single-field assignment, such that we could refrain from
preserving bits that we're yet to overwrite.

I can think of a few possible ways to do it, but I don't understand
why this should be necessary.  Could anyone give me an idea of why
these (D)s should cause any problem?

Could it perhaps be that the full-width BIT_FIELD_REF assignment is
introducing some too-wide shifts or triggering corner cases of
bit-selection instructions?

Thanks,

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