#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.
Yuanfang
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
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 > >