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.
next prev parent 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).