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>
- Date: Fri, 30 Jul 2010 18:22:13 +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"?
Without looking at the patch I have two comments.
First, I heard talks about an aggregate copy propagation pass.
Instead of a new pass I would suggest to rewrite aggregate
variables (partly) into SSA form, extending the DECL_GIMPLE_REG_P
facility. Thus, for each full definition aggr = ... you get
aggr_2 = ..., partial reads of that SSA name should be fine as well
as aggregate uses.
This works for non-aliased variables only of course and requires
some thinking as for DECL_GIMPLE_REG_P as that applies to
the underlying decl which would prohibit creating from
a.a = x;
a = b;
a.a = x;
a_2 = b;
which means that we need to replace the full defs with a new
temporary (with DECL_DEBUG_EXPR_FROM set appropriately),
a.a = x;
tmp_2 = b; // was a
this rewriting should happen in update_address_taken.
SRA should be the place to lower bitfield accesses to loads of
the underlying scalar and the bit extraction via BIT_FIELD_REF.
Stores should be handled via a read-modify-write cycle,
borrowing BIT_FIELD_EXPR as done on the old mem-ref branch.
> Jie Zhang