public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Mark Mitchell <mark@codesourcery.com>
To: Eric Botcazou <ebotcazou@adacore.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Tree SRA and atomicity/volatility
Date: Tue, 23 Jan 2007 16:58:00 -0000	[thread overview]
Message-ID: <45B63E9B.9090909@codesourcery.com> (raw)
In-Reply-To: <200701061422.39157.ebotcazou@adacore.com>

Eric Botcazou wrote:

> 2007-01-06  Eric Botcazou  <ebotcazou@adacore.com>
> 
> 	* tree-sra.c (sra_walk_fns) <ldst>: Document new restriction.
> 	(sra_walk_modify_expr) <rhs_elt>: Treat the reference as a use
> 	if the lhs has side-effects.
> 	<lhs_elt>: Treat the reference as a use if the rhs has side-effects.
>
> :ADDPATCH Tree-SRA:

I've read through this thread, and I think Eric's patch makes sense.  (I
think Richard G. eventually came to the same conclusion, so I'm not
claiming this is some brilliant insight on my part.)  Even in C, keeping
volatile accesses "more atomic" seems like a good thing.  And,
certainly, any possible pessimization by not doing individual accesses
to move data out of volatile structures is going to be insignificant, to
overall program runtime.

As the previous thread about volatile (involving differences, if any,
between scalars and BLKmode objects) shows, it's hard to simultaneously
(a) precisely define volatile and (b) hew to existing
practice/expectations.  But, we can bias the compiler towards more
atomicity, and, in practice, people will be happier with GCC if we don't
try to get too clever in the presence of volatile.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

  parent reply	other threads:[~2007-01-23 16:58 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-06 13:19 Eric Botcazou
2007-01-06 13:31 ` Richard Guenther
2007-01-06 13:47   ` Richard Kenner
2007-01-06 13:49   ` Eric Botcazou
2007-01-07 11:23     ` Richard Guenther
2007-01-08 11:30       ` Eric Botcazou
2007-01-08 11:52         ` Richard Guenther
2007-01-08 12:43           ` Eric Botcazou
2007-01-08 13:12           ` Richard Kenner
2007-01-08 13:40             ` Richard Guenther
2007-01-08 14:55           ` Richard Guenther
2007-01-12 13:57             ` Eric Botcazou
2007-01-12 16:36               ` Richard Guenther
2007-01-12 17:03                 ` Richard Guenther
2007-01-14  7:47                 ` Eric Botcazou
2007-01-14 14:57                   ` Richard Guenther
2007-01-19 13:58                     ` Eric Botcazou
2007-01-23 16:58 ` Mark Mitchell [this message]
2007-01-23 17:15   ` Daniel Berlin
2007-01-23 17:24   ` Richard Guenther
2007-01-23 19:38     ` Mark Mitchell
2007-01-23 20:57       ` Richard Guenther
2007-01-23 22:07         ` Mark Mitchell
2007-01-24  1:39           ` Richard Kenner
2007-01-24 13:33           ` Eric Botcazou
2007-01-24  1:31         ` Richard Kenner
2007-01-24  9:27           ` Richard Guenther
2007-01-24 13:02             ` Richard Kenner
2007-01-24 13:33               ` Richard Guenther
2007-01-24 13:57                 ` Richard Kenner
2007-01-24 18:31                 ` Mark Mitchell
2007-01-24 23:57                   ` Richard Kenner
2007-01-25  9:38                   ` Richard Guenther
2007-01-25 11:38                     ` Richard Kenner
2007-01-25 16:32                       ` Mark Mitchell
2007-01-25 16:41                         ` Richard Guenther
2007-01-25 18:29                           ` Richard Kenner
2007-01-25 22:03                       ` Mike Stump
2007-01-26  2:37                         ` Mark Mitchell
2007-01-26  2:44                           ` Mike Stump
2007-01-26  2:54                             ` Mark Mitchell
2007-01-26  9:17                               ` Richard Guenther
2007-01-26 10:12                                 ` Eric Botcazou
2007-01-26 13:40                                 ` Richard Kenner
2007-01-26 13:13                             ` Richard Kenner
2007-01-26 19:21                               ` Mike Stump
2007-01-24  0:53     ` Richard Kenner
2007-03-02 14:55 ` Eric Botcazou
2007-03-02 15:21   ` Diego Novillo

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=45B63E9B.9090909@codesourcery.com \
    --to=mark@codesourcery.com \
    --cc=ebotcazou@adacore.com \
    --cc=gcc-patches@gcc.gnu.org \
    /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).