This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] Don't completely scalarize a record if it contains bit-field (PR tree-optimization/45144)
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Jie Zhang <jie at codesourcery dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Martin Jambor <mjambor at suse dot cz>
- Date: Sat, 31 Jul 2010 11:48:14 +0200
- Subject: Re: [RFC] Don't completely scalarize a record if it contains bit-field (PR tree-optimization/45144)
- References: <4C52F946.email@example.com>
On Fri, Jul 30, 2010 at 6:09 PM, Jie Zhang <firstname.lastname@example.org> wrote:
> PR tree-optimization/45144 shows an issue that SRA causes. I used
> arm-none-eabi target as an example in PR tree-optimization/45144. But the
> same issue can also been seen on x86_64-linux-gnu target using the same test
> case in the PR.
> SRA completely scalarizes a small record. But when the record is used later
> as a whole, GCC has to make the record out of the scalar parts. When the
> record contains bit-fields, GCC generates ugly code to assemble the scalar
> parts into a record.
> Until the aggregates copy propagation is implemented, I think it would
> better to disable full scalarization for such records. The patch is
> attached. It's bootstrapped on x86_64-linux-gnu and regression tested.
> Is it OK for now? We can remove it after aggregates copy propagation is
> Will it be better to add bit-field check in type_consists_of_records_p
> instead of using a new function "type_contains_bit_field_p"?
The patch looks like a hack. Can you instead make SRA treat the
underlying type of bit-fields as the object for scalarization?
I'm not 100% familiar with the internals, but IIRC SRA builds an
access tree, so for each bitfield load/store the analysis phase should
record an access of the underlying field covering all bits and
a sub-access for the respective member.
Maybe Martin can weight in here.
> Jie Zhang