[llvm] Fix performance bug in buildLocationList (PR #108886)
Jeremy Morse via llvm-commits
llvm-commits at lists.llvm.org
Wed Sep 18 04:07:28 PDT 2024
https://github.com/jmorse commented:
Performance patches most welcome; I can see how stepping through the section-ranges when examining the start-label is going to be faster, and why that necessitates MBBSectionRanges being in the right order.
The change to the end of buildLocationList is less clear however. I believe that section of code is determining whether we should issue a "single-location" location, i.e. saying:
DW_AT_location DW_OP_constu 1234
instead of issuing a location list. I would have imagined that this is unrelated to basic-block-sections: if the variable has the same value across its whole scope, surely it doesn't matter which sections the covered instructions are in, and we don't need to issue a location list anyway if that's true.
Specifically, adding the not-function-end qualifier to this clause:
(RangeIt->second.EndLabel != Asm->getFunctionEnd() &&
CurEntry->getEndSym() != RangeIt->second.EndLabel)
might disable the detection of whether a variable-location-range over the end block is terminated before the end of the block, and allow the issuing of a "single-location" location. Consider this:
entry:
DBG_VALUE 1234
$rax = something
....
end_bb:
$rax = something
DBG_VALUE $noreg
$rax = something_else
ret
Here the variable location covers the whole function except the last instruction -- perhaps there's a late variable assignment that's been optimised away. In this situation we want to issue a location list that covers the whole function except the final instruction, but I believe with this patch (and that extra clause of `RangeIt->second.EndLabel != Asm->getFunctionEnd()`) we'll instead emit a single-location location. That can then lead to a stale/out-of-date variable value being presented to the user on the final instruction of the program.
I might have missed something subtle about the labels though (I'm not familiar with basic-block sections, and it seems fiddly).
https://github.com/llvm/llvm-project/pull/108886
More information about the llvm-commits
mailing list