From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6108 invoked by alias); 26 Jan 2007 02:37:20 -0000 Received: (qmail 6100 invoked by uid 22791); 26 Jan 2007 02:37:20 -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; Fri, 26 Jan 2007 02:37:16 +0000 Received: (qmail 27137 invoked from network); 26 Jan 2007 02:37:14 -0000 Received: from unknown (HELO ?192.168.0.3?) (mitchell@127.0.0.2) by mail.codesourcery.com with ESMTPA; 26 Jan 2007 02:37:14 -0000 Message-ID: <45B96954.9080305@codesourcery.com> Date: Fri, 26 Jan 2007 02:37:00 -0000 From: Mark Mitchell User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Mike Stump CC: Richard Kenner , richard.guenther@gmail.com, 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> <45B7A5E8.3080102@codesourcery.com> <84fc9c000701250138s26cd7932oc00a139c7c321898@mail.gmail.com> <10701251144.AA24290@vlsi1.ultra.nyu.edu> <6FECE966-A8EB-4AC9-8677-48354D50A73B@apple.com> In-Reply-To: <6FECE966-A8EB-4AC9-8677-48354D50A73B@apple.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/msg02154.txt.bz2 Mike Stump wrote: > On Jan 25, 2007, at 3:44 AM, Richard Kenner wrote: >> But we still can't try to express it in any semantically-meaningful way. > > :-( I disagree fundamentally with this notion. gcc, being an > implementation, is free to talk about opcodes produced or not on i686, > if it wants. Sure, that's doable in principle. 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. -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713