================
@@ -95,24 +95,30 @@ template <> struct MappingTraits<bolt::SuccessorInfo> {
namespace bolt {
struct PseudoProbeInfo {
- llvm::yaml::Hex64 GUID;
- uint64_t Index;
- uint8_t Type;
+ uint32_t InlineTreeIndex = 0;
+ uint64_t BlockMask = 0; // bitset with probe indices
----------------
aaupov wrote:
> Could you clarify more on this? why we need a special use for the value 1
> BlockMask, there still could be more probes? say we can have two probes: 1
> basic block probe(ID1) and 1 call probe(ID2).
This is a YAML size optimization: it's very common for the first block to only
have block probe with id 1 (~entry point block probe). In this case the YAML
representation is `{ blk: 1 }`. We can elide it and encode as `{ }`, and treat
that as `{ blk: 1 }`.
If the block has other probes, as in your example, we can't elide `blk: 1`
because we need to distinguish `{ blk: 1, call: [ 2 ] }` from `{ call: [ 2 ] }`
(no block probes).
This optimization only buys us ~1MB (92MB with -> 93MB without).
I agree the effect is low-ish for a special case, so I'll drop it if you react
with thumbs up.
https://github.com/llvm/llvm-project/pull/107137
_______________________________________________
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
