[LLVMdev] PGO for macro expansion code

[Yuanfang Chen]

Thank you, Diego. Just submitted it at
https://llvm.org/bugs/show_bug.cgi?id=23690

I'm profiling the SPEC2006 benchmark to get an idea which loop is hot.
Personally I will write actual functions to avoid this issue :-).

On Thu, May 28, 2015 at 3:44 PM, Diego Novillo <dnovillo at google.com> wrote:
>
>
> On 05/28/15 15:27, Yuanfang Chen wrote:
>>
>> #define GET_BIT(lll)    \
>>      // blah blah
>>
>> #define G(label1,label2)   \
>> {                                      \
>>    // decent amount code  \
>>    ...
>>    while (1) {                       \
>>    GET_BIT(label2);             \
>>    };                                    \
>> }
>>
>> void f() {
>>     if (..)
>>       G('c', 'd');
>>
>>     while ( .. )
>>         G('a','b');
>> }
>>
>> After perf sampling, a lot of samples that should have landed in G and
>> GET_BIT is attributed to the two lines that have G expansion.
>> Discriminator does not work either for this case. However  the last
>> field of DW_TAG_lexical_block ("Unique ID to identify blocks from a
>> template function") is unique for all instances of scopes in G and
>> GET_BIT. Can we use that to get better profile of hot and cold paths
>> inside macro? If not, any workaround for now? Thank you.
>
>
> Could you file a bug report and add me to the CC list? Please include
> details on reproducing it as well (Perf version and how you collected the
> profile).
>
> The problem here is that you have an expansion of an expansion, so the line
> numbering will be jumbled.
>
> A quick workaround will be to avoid using macros. Can you make one of G or
> GET_BIT actual functions? The two calls to GET_BIT in the hot and cold
> regions of f() will have the same line+discr info.
>
>
> Diego.
>>
>> Yuanfang
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>