On Wed, Sep 30, 2015 at 12:03 PM, Tom de Vries <tom_devr...@mentor.com> wrote:
> On 29/09/15 13:29, Richard Biener wrote:
>>
>> On Tue, Sep 29, 2015 at 1:23 PM, Tom de Vries <tom_devr...@mentor.com>
>> wrote:
>>>
>>> On 29/09/15 12:36, Richard Biener wrote:
>>>>
>>>>
>>>> On Tue, Sep 29, 2015 at 7:43 AM, Tom de Vries <tom_devr...@mentor.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> [ was: Re: [RFC] Dump function attributes ]
>>>>>
>>>>> On 28/09/15 17:17, Bernd Schmidt wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 09/28/2015 04:32 PM, Tom de Vries wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> patch below prints the function attributes in the dump file.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> foo ()
>>>>>>> [ noclone , noinline ]
>>>>>>> {
>>>>>>> ...
>>>>>>>
>>>>>>> Good idea?
>>>>>>>
>>>>>>> If so, do we want one attribute per line?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Only for really long ones I'd think. Patch is ok for now.
>>>>>>
>>>>>>
>>>>>
>>>>> Reposting patch with ChangeLog entry added.
>>>>>
>>>>> Bootstrapped and reg-tested on x86_64.
>>>>>
>>>>> Committed to trunk.
>>>>
>>>>
>>>>
>>>> Hmpf. I always like to make the dump-files as much copy&past-able to
>>>> testcases
>>>> as possible.
>>>
>>>
>>>
>>> Hmm, interesting. Not something I use, but I can imagine it's useful.
>>>
>>>> So why did you invent a new syntax for attributes instead of using
>>>> the existing __attribute__(("noclone", "noinline")) (in this case)?
>>>
>>>
>>>
>>> My main concerns were:
>>> - being able to see in dump files what the actual attributes of a
>>> function are (rather than having to figure it out in a debug session).
>>> - being able to write testcases that can test for the presence of those
>>> attributes in dump files
>>>
>>>> Did you verify
>>>> how attributes with arguments get printed?
>>>
>>>
>>>
>>> F.i. an oacc offload function compiled by the host compiler is annotated
>>> as
>>> follows:
>>>
>>> before pass_oacc_transform (in the gomp-4_0-branch):
>>> ...
>>> [ oacc function 32, , , omp target entrypoint ]
>>> ...
>>>
>>> after pass_oacc_transform:
>>> ....
>>> [ oacc function 1, 1, 1, omp target entrypoint ]
>>> .
>>
>>
>> Hmm, ok. So without some extra dump_attribute_list wrapping
>> __attribute_(( ... )) around the above doesn't make it more amenable
>> for cut&pasting.
>>
>
> With attached untested follow-up patch, for test-case:
> ...
> void __attribute__((noinline)) __attribute__((alias ("bar"), noclone))
> foo (void)
> {
>
> }
>
> void __attribute__ ((__target__ ("arch=core2", "sse3")))
> foo2 (void)
> {
>
> }
>
> void __attribute__ ((optimize ((1))))
> foo3 (void)
> {
>
> }
>
> void __attribute__ ((optimize (("1"))))
> foo4 (void)
> {
>
> }
> ...
>
> I get at gimple dump:
> ...
> __attribute__((noclone, alias ("bar"), noinline))
> foo ()
> {
>
> }
>
>
> __attribute__((__target__ ("arch=core2", "sse3")))
> foo2 ()
> {
>
> }
>
>
> __attribute__((optimize (1)))
> foo3 ()
> {
>
> }
>
>
> __attribute__((optimize ("1")))
> foo4 ()
> {
>
> }
> ...
>
> OK if bootstrap/regtest succeeds?
Ok.
Thanks,
Richard.
> Thanks,
> - Tom
>
