[llvm-profgen] Fix a bug of assertion

[wlei]

Summary

The assertion should work on the entire context.

[hoy]

Good catch. What is the case you saw that the call stack has only one leaf frame? Is it in the main function?

[wenlei]

Thanks! I have the same question as hongtao, but the change lgtm.

[wlei]

In D110268#3015817, @hoy wrote:

Good catch. What is the case you saw that the call stack has only one leaf frame? Is it in the main function?

Good question. main should be one case if it hit any samples. In my run, it showed like below. seems it's from external lib.

jemalloc_je_edata_heap_insert
jemalloc_je_arena_dalloc_bin_locked_handle_newly_nonempty
jemalloc_je_edata_heap_remove_first
jemalloc_je_arena_cache_bin_fill_small
extent_record
_ZdlPvm

Not sure why this doesn't have context.

[wenlei]

In D110268#3016367, @wlei wrote:

In D110268#3015817, @hoy wrote:

Good catch. What is the case you saw that the call stack has only one leaf frame? Is it in the main function?

Good question. main should be one case if it hit any samples. In my run, it showed like below. seems it's from external lib.

jemalloc_je_edata_heap_insert
jemalloc_je_arena_dalloc_bin_locked_handle_newly_nonempty
jemalloc_je_edata_heap_remove_first
jemalloc_je_arena_cache_bin_fill_small
extent_record
_ZdlPvm

Not sure why this doesn't have context.

perhaps external code called these allocator functions. we're not going to optimize these anyways.

[hoy]

In D110268#3016367, @wlei wrote:

In D110268#3015817, @hoy wrote:

Good catch. What is the case you saw that the call stack has only one leaf frame? Is it in the main function?

Good question. main should be one case if it hit any samples. In my run, it showed like below. seems it's from external lib.

jemalloc_je_edata_heap_insert
jemalloc_je_arena_dalloc_bin_locked_handle_newly_nonempty
jemalloc_je_edata_heap_remove_first
jemalloc_je_arena_cache_bin_fill_small
extent_record
_ZdlPvm

Not sure why this doesn't have context.

I see, it's not user code. Probably because jemalloc isn't built with fp omission off.

[wlei]

perhaps external code called these allocator functions. we're not going to optimize these anyways.

I see, it's not user code. Probably because jemalloc isn't built with fp omission off.

I see, thanks for the context.

llvm/tools/llvm-profgen/ProfiledBinary.cpp

for (auto Address : Stack) {
     if (ExpandedContext.empty())
       return SampleContextFrameVector();
     // Set WasLeafInlined to the size of inlined frame count for the last
     // address which is leaf
     WasLeafInlined = (ExpandedContext.size() > 1);
     ContextVec.append(ExpandedContext);
   }
 
+  assert(ContextVec.size() && "Context length should be at least 1");
+
   // Compress the context string except for the leaf frame
   auto LeafFrame = ContextVec.back();
   LeafFrame.Callsite = LineLocation(0, 0);
   ContextVec.pop_back();
-  assert(ContextVec.size() && "Context length should be at least 1");
   CSProfileGenerator::compressRecursionContext(ContextVec);
   CSProfileGenerator::trimContext(ContextVec);
   ContextVec.push_back(LeafFrame);
   return ContextVec;
 }
 
 template <class ELFT>
 void ProfiledBinary::setPreferredTextSegmentAddresses(const ELFFile<ELFT> &Obj, StringRef FileName) {