This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On May  6, 2007, Eric Botcazou <ebotcazou@adacore.com> wrote:

>> Would you please let me know whether this is still the case for the
>> patch I've just posted in the thread "Reload bug & SRA oddness"?
>> http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00317.html

> Well, you can just build the Ada compiler (it builds now) on your preferred 
> platform and run it on the testcase at -O.  There should be no BIT_FIELD_REF 
> at all after SRA.

No, you talked about ICEs.  I regularly build the Ada compiler (and I
did even at the time it was broken in mainline because I was working
on a tree from before the breakage), and I haven't seen any such ICEs.

The BIT_FIELD_REFs you're talking about are a separate issue, that
follows from a misunderstanding of the purpose of the patch.

>> I'm not sure why this is bad, if the bitfield access patterns are
>> whole-word accesses, which presumably access a single register.

> If this reasoning was true, then why not simply replace all COMPONENT_REFs 
> with BIT_FIELD_REFs?

Because the compiler can't keep track of component_refs as much as it
can of gimple registers, so it does a poorer job at optimizing them.

> I'd simply test DECL_BIT_FIELD.

The point is that I'm trying to avoid register explosion for
aggregates with many small members that are not accessed directly.
They can be bit-fields, but they can also be chars or shorts.  If we
don't access them directly, only copy them around, keeping them in a
single hardware register is far more efficient than performing byte or
short access and using multiple registers.

So using DECL_BIT_FIELD might seem right because the patch happens to
fix bit-field issues, but it narrows the scope of the solution,
because then it doesn't apply to other narrow fields that would
likely be beneficial to handle.

Of course there are trade-offs here.  If there are two instances of a
struct, and one of them is scalarized into one gimple register per
field, while the other is scalarized with a single gimple register for
a few of the fields, copying between them will involve more complex
operations than if both had been scalarized the same way.  For sure
there is room for improvement, particularly in the code to copy from
the all-fields-scalarized object to the some-fields-in-a-block one.

But how bad do we do after the patch, and how does it compare with
what we did before the patch?

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]