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.
Richard.
>
> Thanks,
> - Tom
