From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12918 invoked by alias); 24 Jan 2007 18:31:20 -0000 Received: (qmail 12902 invoked by uid 22791); 24 Jan 2007 18:31:19 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 24 Jan 2007 18:31:12 +0000 Received: (qmail 17527 invoked from network); 24 Jan 2007 18:31:10 -0000 Received: from unknown (HELO ?192.168.0.3?) (mitchell@127.0.0.2) by mail.codesourcery.com with ESMTPA; 24 Jan 2007 18:31:10 -0000 Message-ID: <45B7A5E8.3080102@codesourcery.com> Date: Wed, 24 Jan 2007 18:31:00 -0000 From: Mark Mitchell User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Richard Guenther CC: Richard Kenner , ebotcazou@adacore.com, gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Tree SRA and atomicity/volatility References: <200701061422.39157.ebotcazou@adacore.com> <45B63E9B.9090909@codesourcery.com> <84fc9c000701230924g37ed4f42vca8d7ae0c1ef6e52@mail.gmail.com> <45B6643C.6000800@codesourcery.com> <84fc9c000701231257u7fb1f10rdd3255be8aa69686@mail.gmail.com> <10701240137.AA23316@vlsi1.ultra.nyu.edu> <84fc9c000701240127x2fe9492bq355cd35260e7b55e@mail.gmail.com> <10701241307.AA01425@vlsi1.ultra.nyu.edu> <84fc9c000701240533p217a2735i8e42634e07029df7@mail.gmail.com> In-Reply-To: <84fc9c000701240533p217a2735i8e42634e07029df7@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2007-01/txt/msg02017.txt.bz2 Richard Guenther wrote: > I'm asking for a specification, for constraints -- if you want to > guarantee what > you said you should specify it. I'm for leaving it as undefined (which > is what > we have now). Like if you have a large "volatile" structure gcc might > still > use memcpy to copy it? The memcpy implementation might touch parts > of the structure twice to, for example, prime the cache. Yes, I would consider it a bug to use memcpy to implement structure assignment from/to a volatile structure, for exactly the reason you state. I think you can get that directly from the C standard, which says that the number of accesses to volatile memory is exactly the number that appear in the program. One might also argue that it would be a bug for the compiler to generate a byte-wise copy inline (rather than a word-wise) copy, since that, too, will result in additional accesses on most hardware. I'd be more forgiving there, but it's a question of degree. I think the issue that you're struggling with is that volatile is not entirely well-defined. It's a specification at the language level of something that has machine-specific semantics. There's a big huge "implementation-defined" cloud hanging over it. If we were building a compiler designed only for us on (say) ARM chips, then maybe we could go further in saying exactly what it means. But, with GCC's full generality, we can't say exactly. That doesn't mean that volatile isn't useful, or that we shouldn't make efforts to make it meaningful. As a programmer, I would try hard to minimize my reliance on volatile for exactly this reason. On a 32-bit machine, I'd expect the compiler to handle "volatile int" by using 32-bit word-aligned loads/stores. But, I would try to avoid "struct S { volatile char a; volatile char b; }", if reading/writing "a" and "b" had side-effects, because I wouldn't know exactly what that might do. I'd use inline assembly if I needed that fine level of control. As a compiler developer, I would try to make the compiler be "as atomic as possible". So, for example, when copying from a volatile structure, I'd try to do a block copy (rather than call memcpy), and I would avoid SRA-ing a volatile structure. In other words, I would try to be defensive -- whether acting as programmer or compiler developer -- and hope that then most programs using volatile would behave as I expect -- because programmers don't expect too much and because compilers do as well as possible. -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713