From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-306856-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 28387 invoked by alias); 5 Nov 2011 22:09:50 -0000
Received: (qmail 28371 invoked by uid 22791); 5 Nov 2011 22:09:49 -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-gx0-f175.google.com (HELO mail-gx0-f175.google.com) (209.85.161.175)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 05 Nov 2011 22:09:34 +0000
Received: by ggnp1 with SMTP id p1so1192668ggn.20        for <gcc-patches@gcc.gnu.org>; Sat, 05 Nov 2011 15:09:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.74.37 with SMTP id q5mr3143940obv.32.1320530973403; Sat, 05 Nov 2011 15:09:33 -0700 (PDT)
Received: by 10.182.17.232 with HTTP; Sat, 5 Nov 2011 15:09:33 -0700 (PDT)
In-Reply-To: <4EB5A537.1090204@redhat.com>
References: <4EB2EACC.8050307@redhat.com>	<CAFiYyc0j5vsrt_BrTzaKO+pNANqfnO3Avwq=ts7wDHRbbrAGug@mail.gmail.com>	<4EB5A537.1090204@redhat.com>
Date: Sat, 05 Nov 2011 23:16:00 -0000
Message-ID: <CAFiYyc3gfKJ1HVsJTjpSZQH+LS-j5TZtCb3m83QE72NGLXbNcg@mail.gmail.com>
Subject: Re: [patch] 19/n: trans-mem: compiler tree/gimple stuff
From: Richard Guenther <richard.guenther@gmail.com>
To: Aldy Hernandez <aldyh@redhat.com>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>, Richard Henderson <rth@redhat.com>
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: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
X-SW-Source: 2011-11/txt/msg00746.txt.bz2

On Sat, Nov 5, 2011 at 10:05 PM, Aldy Hernandez <aldyh@redhat.com> 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_pure"=
));
>>
>> 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 easier.
>
> 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 funct=
ion
> 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 inter=
face
via attributes.  What's the semantic of transaction-pure vs. ...

> I don't see what the flag buys us. =A0Or am I misunderstanding something?
>
>>> +/* 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 deferr=
ing
> to rth and then fixing if required.

Yeah, seems to be still an open question.

Thanks,
Richard.