From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8689 invoked by alias); 23 Jan 2007 17:15:29 -0000 Received: (qmail 8680 invoked by uid 22791); 23 Jan 2007 17:15:29 -0000 X-Spam-Check-By: sourceware.org Received: from wx-out-0506.google.com (HELO wx-out-0506.google.com) (66.249.82.228) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 23 Jan 2007 17:15:24 +0000 Received: by wx-out-0506.google.com with SMTP id h30so1754508wxd for ; Tue, 23 Jan 2007 09:15:22 -0800 (PST) Received: by 10.90.105.20 with SMTP id d20mr8276005agc.1169572522416; Tue, 23 Jan 2007 09:15:22 -0800 (PST) Received: by 10.90.73.5 with HTTP; Tue, 23 Jan 2007 09:15:22 -0800 (PST) Message-ID: <4aca3dc20701230915g3c4938b2nbbd53fe0ddfeba03@mail.gmail.com> Date: Tue, 23 Jan 2007 17:15:00 -0000 From: "Daniel Berlin" To: "Mark Mitchell" Subject: Re: [PATCH] Tree SRA and atomicity/volatility Cc: "Eric Botcazou" , gcc-patches@gcc.gnu.org In-Reply-To: <45B63E9B.9090909@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200701061422.39157.ebotcazou@adacore.com> <45B63E9B.9090909@codesourcery.com> 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/msg01903.txt.bz2 On 1/23/07, Mark Mitchell wrote: > Eric Botcazou wrote: > > > 2007-01-06 Eric Botcazou > > > > * tree-sra.c (sra_walk_fns) : Document new restriction. > > (sra_walk_modify_expr) : Treat the reference as a use > > if the lhs has side-effects. > > : 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. > 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. I agree the principle of his patch makes sense, but i'm not sure of the implementation. If it's really checking for volatility, we have stmt->has_volatile_operands, and this should be checked, rather than every tree single operand. We simply don't touch statements with volatile operands. That appears not to be the case here (he's checking for some property we don't expose in the middle end), in which case I guess testing TREE_SIDE_EFFECTS make sense, but i'm very worried about the idea that we are going to need to test every tree operand before making a transformation, which is pretty expensive. That is one of the reasons we have stmt_ann->has_volatile_ops in the first place - so optimizers could make quick decisions about whether they should be touching something or not. If the only place this will ever be tested is SRA, i'm okay with it. I have a nagging feeling it's not, particularly as we get into more loop opts (predictive commoning, etc) and i don't want to see us say "well, everyone was fine with us testing every tree operand then".