[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