From: Mark Mitchell <mark@codesourcery.com>
To: Eric Botcazou <ebotcazou@libertysurf.fr>
Cc: Jakub Jelinek <jakub@redhat.com>,
gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: GCC Status Report (2004-03-09)
Date: Fri, 19 Mar 2004 20:23:00 -0000 [thread overview]
Message-ID: <405B4073.5000105@codesourcery.com> (raw)
In-Reply-To: <200403191934.34104.ebotcazou@libertysurf.fr>
Eric Botcazou wrote:
>>Well, so, let's remove that chunk of code; it should no longer be needed.
>>
>>
>
>
>Do you want me to revert that patch?
>
>
>
Yes -- if your tests confirm that it is safe to do so.
>>Eric, I can tell you're unhappy with this approach, and so you're
>>casting about for something better. That's good, but I think we've come
>>as far as we can for 3.4.0.
>>
>>
>
>Yes, I'm pretty frustrated because we're (again) chasing down a far-reaching
>bug just days before a release.
>
>
>
Yes. This bug has been lying around for a long time, and we were all
afraid to tackle it. The long-term solution is clearer interfaces and
specifications so that it's more obvious what's wrong; the problem here
is that none of us quite know what this code is supposed to do.
>Before I start thinking about a replacement, I'd like to understand what I'll
>be trying the replace. It appears that no-bo-dy can tell what is the
>purpose of RTX_UNCHANGING_P.
>
>
It's supposed to be the RTL equivalent of "const". In other words, once
initialized, an RTX_UNCHANGING_P thing is immutable, and therefore no
writes can alias it. If you're after the one write to the
RTX_UNCHANGING_P thing, then it's value is always valid. That's true
even if someone has its address; they cannot write through the pointer.
This is clearly a valuable optimization aid. I think that simply making
this flag a tri-state will be the cleanest fix. For memory to which
this clearing optimization applies, the flag should not be set, because
the memory is written twice. If we're worried about pessimization in
that case, we should avoid writing the memory twice.
Frankly, I suspect that there is virtually no real code where writing
only to the holes (where "holes" means "fields that are not explicitly
initialized to a non-zero value, and, if the compiler so desires, parts
of the object that are not part of any field") has any observable
performance from clearing the whole structure. If most of the structure
is zero, then that will certainly be true. If only a tiny bit of the
structure is non-zero, that will certainly be true. If the non-zero
parts are contiguous, that will probably be true. In practice, there
are few inner loops involving initializing every other field in a
structure, and that is the case where we would lose.
--
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com
next prev parent reply other threads:[~2004-03-19 18:48 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
2004-03-19 19:29 ` Mark Mitchell
2004-03-19 20:04 ` Eric Botcazou
2004-03-19 20:23 ` Mark Mitchell [this message]
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=405B4073.5000105@codesourcery.com \
--to=mark@codesourcery.com \
--cc=ebotcazou@libertysurf.fr \
--cc=gcc-patches@gcc.gnu.org \
--cc=gcc@gcc.gnu.org \
--cc=jakub@redhat.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).