From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3566 invoked by alias); 7 Nov 2011 22:27:49 -0000 Received: (qmail 3557 invoked by uid 22791); 7 Nov 2011 22:27:48 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-ey0-f175.google.com (HELO mail-ey0-f175.google.com) (209.85.215.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 07 Nov 2011 22:27:34 +0000 Received: by eyd9 with SMTP id 9so4778645eyd.20 for ; Mon, 07 Nov 2011 14:27:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.212.33 with SMTP id nh1mr9558496obc.72.1320704853067; Mon, 07 Nov 2011 14:27:33 -0800 (PST) Received: by 10.182.17.232 with HTTP; Mon, 7 Nov 2011 14:27:32 -0800 (PST) In-Reply-To: <4EB82AEF.7000208@redhat.com> References: <4EB2EACC.8050307@redhat.com> <4EB5A537.1090204@redhat.com> <4EB82AEF.7000208@redhat.com> Date: Mon, 07 Nov 2011 22:38:00 -0000 Message-ID: Subject: Re: [patch] 19/n: trans-mem: compiler tree/gimple stuff From: Richard Guenther To: Richard Henderson Cc: Aldy Hernandez , gcc-patches Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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: 2011-11/txt/msg01086.txt.bz2 On Mon, Nov 7, 2011 at 8:01 PM, Richard Henderson wrote: > On 11/05/2011 03:09 PM, Richard Guenther wrote: >> On Sat, Nov 5, 2011 at 10:05 PM, Aldy Hernandez wrote: >>> [rth, see below] >>> >>>>> =A0 local_define_builtin ("__builtin_eh_pointer", ftype, >>>>> BUILT_IN_EH_POINTER, >>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"__builtin_eh_pointer"= , ECF_PURE | ECF_NOTHROW | >>>>> ECF_LEAF); >>>>> + =A0if (flag_tm) >>>>> + =A0 =A0apply_tm_attr (builtin_decl_explicit (BUILT_IN_EH_POINTER), >>>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0get_identifier ("transaction_pur= e")); >>>> >>>> I think this should use a new ECF_TM_PURE flag, unconditionally set >>>> with handling in the functions that handle/return ECF flags so that >>>> transitioning this to a tree node flag instead of an attribute is easi= er. >>> >>> I could add a ECF_TM_PURE flag and attach it to the BUILT_IN_EH_POINTER= in >>> the local_define_builtin above, but we still need the attribute for fun= ction >>> decl's as in: >>> >>> __attribute__((transaction_pure)) void foo(); >>> >>> Attributes seem like a clean way to approach this. >> >> The middle-end interfacing is supposed to be via ECF_ flags, the user in= terface >> via attributes. =A0What's the semantic of transaction-pure vs. ... >> >>> I don't see what the flag buys us. =A0Or am I misunderstanding somethin= g? >>> >>>>> +/* Nonzero if this call performs a transactional memory operation. = =A0*/ >>>>> +#define ECF_TM_OPS =A0 =A0 =A0 =A0 =A0 =A0 =A0 (1<< =A011) >>>> >>>> What's this flag useful for? =A0Isn't it the case that you want to >>>> conservatively >>>> know whether a call might perform a tm operation? =A0Thus, the flag >>>> should be inverted? =A0Is this the same as "TM pure"? >> >> ... this? >> >>> Richard? >> >>> Richi, I have fixed or addressed all the issues in this thread, with the >>> exception of your EFC_TM_PURE and ECF_TM_OPS questions, which I am defe= rring >>> to rth and then fixing if required. >> >> Yeah, seems to be still an open question. > > I hope this cleanup both addresses the above questions and tidies things > up as indicated. =A0Please ask if you've got more questions. > > Ok, Richi? Yes, Thanks, Richard. > > r~ >