From: Richard Guenther <richard.guenther@gmail.com>
To: Jie Zhang <jie@codesourcery.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>, Martin Jambor <mjambor@suse.cz>
Subject: Re: [RFC] Don't completely scalarize a record if it contains bit-field (PR tree-optimization/45144)
Date: Sat, 31 Jul 2010 10:01:00 -0000 [thread overview]
Message-ID: <AANLkTim0pobdibGOWL0vAs5KUpERp3dmUO9kKqx8d3_k@mail.gmail.com> (raw)
In-Reply-To: <4C52F946.6010404@codesourcery.com>
On Fri, Jul 30, 2010 at 6:09 PM, Jie Zhang <jie@codesourcery.com> 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
> implemented.
>
> 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.
Richard.
>
> Regards,
> --
> Jie Zhang
> CodeSourcery
>
next prev parent reply other threads:[~2010-07-31 9:48 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-30 16:21 Jie Zhang
2010-07-30 16:37 ` Richard Guenther
2010-07-30 17:27 ` Mark Mitchell
2010-07-30 17:53 ` Jakub Jelinek
2010-07-30 18:53 ` Mark Mitchell
2010-07-30 18:59 ` Richard Kenner
2010-07-30 19:39 ` Andrew Pinski
2010-07-30 19:48 ` Mark Mitchell
2010-08-02 4:10 ` Jie Zhang
2010-07-31 9:48 ` Richard Guenther
2010-07-31 9:48 ` Richard Guenther
2010-08-02 13:25 ` Martin Jambor
2010-08-02 4:01 ` Jie Zhang
2010-08-02 3:28 ` Jie Zhang
2010-08-02 16:52 ` Mark Mitchell
2010-08-03 9:00 ` Richard Guenther
2010-08-03 9:59 ` Jie Zhang
2010-07-31 10:01 ` Richard Guenther [this message]
2010-08-02 4:29 ` Jie Zhang
2010-08-02 13:01 ` Martin Jambor
2010-08-04 11:53 ` Jie Zhang
2010-08-04 12:23 ` Richard Guenther
2010-08-04 19:41 ` Martin Jambor
2010-08-05 3:12 ` Jie Zhang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AANLkTim0pobdibGOWL0vAs5KUpERp3dmUO9kKqx8d3_k@mail.gmail.com \
--to=richard.guenther@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jie@codesourcery.com \
--cc=mjambor@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).