On Mon, Nov 7, 2011 at 8:01 PM, Richard Henderson <r...@redhat.com> wrote:
> On 11/05/2011 03:09 PM, Richard Guenther wrote:
>> On Sat, Nov 5, 2011 at 10:05 PM, Aldy Hernandez <al...@redhat.com> wrote:
>>> [rth, see below]
>>>
>>>>> local_define_builtin ("__builtin_eh_pointer", ftype,
>>>>> BUILT_IN_EH_POINTER,
>>>>> "__builtin_eh_pointer", ECF_PURE | ECF_NOTHROW |
>>>>> ECF_LEAF);
>>>>> + if (flag_tm)
>>>>> + apply_tm_attr (builtin_decl_explicit (BUILT_IN_EH_POINTER),
>>>>> + get_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 function
>>> 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
>> interface
>> via attributes. What's the semantic of transaction-pure vs. ...
>>
>>> I don't see what the flag buys us. Or am I misunderstanding something?
>>>
>>>>> +/* Nonzero if this call performs a transactional memory operation. */
>>>>> +#define ECF_TM_OPS (1<< 11)
>>>>
>>>> What's this flag useful for? Isn't it the case that you want to
>>>> conservatively
>>>> know whether a call might perform a tm operation? Thus, the flag
>>>> should be inverted? Is 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 deferring
>>> 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. Please ask if you've got more questions.
>
> Ok, Richi?
Yes,
Thanks,
Richard.
>
> r~
>
