aaupov wrote: > Could you elaborate a bit better on why do we need a deleted block to be > present in the table? My memory fails me, aren't we using the translation > table just to map samples collected on the bolted binary? Where do the > deleted blocks become a problem? > > Other than the motivation, the implementation itself looks good to me.
We need deleted blocks to correctly map optimized tail calls to containing basic blocks. Because we expand tail calls during CFG construction, and attach the profile to that CFG, we need those intermediate blocks to be present in the profile. bb -with-two-tail-calls offers a good example: after building CFG (details omitted): ``` .LBB00 (1 instructions, align : 1) 00000000: je .Ltmp0 # Offset: 0 .LFT0 (2 instructions, align : 1) 00000002: ja .Ltmp1 # Offset: 2 00000004: jmp .Ltmp2 # Offset: 4 .Ltmp0 (1 instructions, align : 1) 00000006: retq # Offset: 6 .Ltmp1 (1 instructions, align : 1) 00000007: jmp e # TAILCALL # Offset: 7 .Ltmp2 (2 instructions, align : 1) 0000000c: nop # Offset: 12 # Size: 1 # NOP: 1 0000000d: jmp f # TAILCALL # Offset: 13 ``` after SCTC, we normally write out BAT from that state: ``` .LBB00 (1 instructions, align : 1) 00000000: je .Ltmp0 # Offset: 0 .LFT0 (2 instructions, align : 1) 00000002: ja e # TAILCALL # Offset: 7 # CTCTakenCount: 4 00000004: jmp f # TAILCALL # Offset: 13 .Ltmp0 (1 instructions, align : 1) 00000009: retq # Offset: 6 ``` So in order to map this branch ``` 00000004: jmp f # TAILCALL # Offset: 13 ``` to its block Ltmp2 we need to preserve the block entry in BAT, although it's removed from CFG. https://github.com/llvm/llvm-project/pull/91906 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits