From: Eric Botcazou <ebotcazou@libertysurf.fr>
To: Jakub Jelinek <jakub@redhat.com>
Cc: Mark Mitchell <mark@codesourcery.com>,
gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: GCC Status Report (2004-03-09)
Date: Fri, 19 Mar 2004 14:31:00 -0000 [thread overview]
Message-ID: <200403191413.10043.ebotcazou@libertysurf.fr> (raw)
In-Reply-To: <20040318233552.GI31589@devserv.devel.redhat.com>
> Can't we at least detect the case where either the whole aggregate
> is const or all its fields are const? Then we don't need any blockage.
Guess what? The constness is not propagated to the RTL in the former case,
because of the pessimization recently introduced in maybe_set_unchanging:
We cannot do this for non-static aggregates, because of the double
writes that can be generated by store_constructor, depending on the
contents of the initializer. Yes, this does eliminate a good fraction
of the number of uses of RTX_UNCHANGING_P for a language like Ada.
It also eliminates a good quantity of bugs. Let this be incentive to
eliminate RTX_UNCHANGING_P entirely in favor of a more reliable
solution, perhaps based on alias sets. */
This means that const automatic aggregates would take a double pessimization
with the blockage scheme.
--
Eric Botcazou
next prev parent reply other threads:[~2004-03-19 13:06 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-09 18:09 Mark Mitchell
2004-03-11 9:45 ` Eric Botcazou
2004-03-11 12:48 ` Jakub Jelinek
2004-03-11 21:11 ` Richard Henderson
2004-03-16 16:53 ` Mark Mitchell
2004-03-16 16:59 ` Paul Koning
2004-03-16 17:11 ` Ian Lance Taylor
2004-03-16 17:24 ` Zack Weinberg
2004-03-16 17:25 ` Paul Koning
2004-03-17 10:56 ` Eric Botcazou
2004-03-17 11:49 ` Eric Botcazou
2004-03-17 15:55 ` Mark Mitchell
2004-03-18 8:25 ` Eric Botcazou
2004-03-18 18:31 ` Eric Botcazou
2004-03-18 19:15 ` Mark Mitchell
2004-03-18 23:36 ` Eric Botcazou
2004-03-18 23:41 ` Jakub Jelinek
2004-03-19 1:23 ` Eric Botcazou
2004-03-19 14:31 ` Eric Botcazou [this message]
2004-03-19 19:29 ` Mark Mitchell
2004-03-19 20:04 ` Eric Botcazou
2004-03-19 20:23 ` Mark Mitchell
2004-03-20 19:51 ` Eric Botcazou
[not found] ` <405A3F26.2050100@codesourcery.com>
[not found] ` <200403190155.18981.ebotcazou@libertysurf.fr>
2004-03-19 6:42 ` Mark Mitchell
2004-03-16 2:09 ` C++ status (Was: GCC Status Report (2004-03-09)) Giovanni Bajo
2004-03-11 12:15 GCC Status Report (2004-03-09) Richard Kenner
2004-03-11 12:39 ` Eric Botcazou
2004-03-11 12:49 Richard Kenner
2004-03-11 14:09 ` Eric Botcazou
2004-03-19 6:34 Richard Kenner
2004-03-19 12:18 ` Jakub Jelinek
2004-03-19 14:22 Richard Kenner
2004-03-19 20:08 Richard Kenner
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=200403191413.10043.ebotcazou@libertysurf.fr \
--to=ebotcazou@libertysurf.fr \
--cc=gcc-patches@gcc.gnu.org \
--cc=gcc@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=mark@codesourcery.com \
/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).