From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14473 invoked by alias); 26 Jan 2007 13:13:53 -0000 Received: (qmail 14464 invoked by uid 22791); 26 Jan 2007 13:13:52 -0000 X-Spam-Check-By: sourceware.org Received: from VLSI1.ULTRA.NYU.EDU (HELO vlsi1.ultra.nyu.edu) (128.122.140.213) by sourceware.org (qpsmtpd/0.31) with SMTP; Fri, 26 Jan 2007 13:13:41 +0000 Received: by vlsi1.ultra.nyu.edu (4.1/1.34) id AA21003; Fri, 26 Jan 07 08:19:20 EST From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Message-Id: <10701261319.AA21003@vlsi1.ultra.nyu.edu> Date: Fri, 26 Jan 2007 13:13:00 -0000 To: mrs@apple.com Subject: Re: [PATCH] Tree SRA and atomicity/volatility Cc: ebotcazou@adacore.com, gcc-patches@gcc.gnu.org, mark@codesourcery.com, richard.guenther@gmail.com In-Reply-To: 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> <45B7A5E8.3080102@codesourcery.com> <84fc9c000701250138s26cd7932oc00a139c7c321898@mail.gmail.com> <10701251144.AA24290@vlsi1.ultra.nyu.edu> <6FECE966-A8EB-4AC9-8677-48354D50A73B@apple.com> <45B96954.9080305@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/msg02186.txt.bz2 > On Jan 25, 2007, at 6:37 PM, Mark Mitchell wrote: > > But, once you write it down, you get to figure out how to make sure > > that > > the entire compiler honors it, including the machine-independent > > TREE-SSA bits. Since the sensible choices may be different for each > > CPU, how to enforce the right constraints (either separately for each > > CPU, or some superset of all of them) may not be easy. > > Well, you know not writing it down doesn't absolve us from having to > get it right anyway. I'd further say that writing it does should not > constrain us from fixing the wording if the wording is broken, but I > agree, if we write it down, it would be better to have the right > theoretic answer and leave unspecified those bits that should be. I think the point here is that writing it down at the level you suggested (opcode choices) *overspecifies* things and creates an unrealistic burden on the implementation, especially because if you do it that way, you have to do it for all targets.