public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Mike Stump <mrs@apple.com>
To: Richard Kenner <kenner@vlsi1.ultra.nyu.edu>
Cc: ebotcazou@adacore.com, gcc-patches@gcc.gnu.org,
	mark@codesourcery.com,         richard.guenther@gmail.com
Subject: Re: [PATCH] Tree SRA and atomicity/volatility
Date: Fri, 26 Jan 2007 19:21:00 -0000	[thread overview]
Message-ID: <BB59FDD6-4665-427C-9B47-AC542CC7B847@apple.com> (raw)
In-Reply-To: <10701261319.AA21003@vlsi1.ultra.nyu.edu>

On Jan 26, 2007, at 5:19 AM, Richard Kenner wrote:
> I think the point here is that writing it down at the level you  
> suggested

You read way to much into it, if you look again, I didn't state that  
we should overspecify it, I said that we had the freedom to talk  
about chipset, if we waned to.  A language standard cannot.  A  
compiler implementation can, if it _wants_ to, if it _needs_ to.   
Again, let me repeat, I'm not arguing that it needs to.

Let me give you an example, let's say that we have two volatile  
objects and an operation to perform on them.  Let's say the machine  
we're generating code for doesn't have that operation, but that it  
can be decomposed into smaller operations.  We are free to document  
the backend must not decompose the operation and leave the volatile  
objects as operands.  Or, we are free to leave it unspecified.  Ada  
might even have a mandate here.  C might as well.  I don't think I've  
seen it argued here if decomposition is allowed or not.  Now, this  
might be so trivial to those in the know that can't believe anyone  
would get something so basic wrong, and yet, I can see an expander  
for an operation split things up, fail to check for volatile.  The  
documentation would be so that people that might not know the answer  
to read it once, and then have a firm, specific grasp on the subject  
matter so that to them it is then perfectly clear decomposition is  
wrong, obvious if you will.

  reply	other threads:[~2007-01-26 19:21 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
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 [this message]
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=BB59FDD6-4665-427C-9B47-AC542CC7B847@apple.com \
    --to=mrs@apple.com \
    --cc=ebotcazou@adacore.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=kenner@vlsi1.ultra.nyu.edu \
    --cc=mark@codesourcery.com \
    --cc=richard.guenther@gmail.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).