[llvm] [llvm][DebugInfo] Emit 0/1 for constant boolean values (PR #151225)

Jeremy Morse via llvm-commits llvm-commits at lists.llvm.org
Wed Sep 10 02:33:59 PDT 2025


jmorse wrote:

Breaking out from the inline thread into the main one -- sorry for the silence, I've been sunk by other stuff over the holidays,

I'm leaning towards agreeing with @Michael137, while this patch is good I think the problem is better solved in instruction-selection. Looking at the history of the highlighted code, the sign extension appeared in 563fe3cc12 (svn r99469), where there isn't any indication that sign-extending to all-ones is the intended behaviour of the patch.

Stepping back further, a lot of this variation comes from the fact that type-system for variable locations is non-existent (cc @slinder1 ). Booleans will take on the IR type of whatever the bool is stored-as or computed by: in this godbolt example https://godbolt.org/z/PWodh7qo1 in the "beans" function output, the inlined boolean variable "bar" is described by constants with both i8 and i1 type (see metadata node !22). This is because the first dbg.value is a constant promoted off the stack where it's stored as an i8, while the second dbg.value comes from an icmp instruction. I reckon with a bit more work we could create an example where the Boolean True value is represented as both 1 and -1 in the same function after isel, which is IMO undesirable.

I don't fully understand the context about NVPTX describing True with -1: I assume it's alright to always describe True with positive 1 in DWARF even if negative 1 is an option, and debuggers will "just know" how to fixup the two. IMHO (and there's a reasonable chance I'm wrong) the appearance of `DBG_VALUE -1` in LLVM is unintentional and the correspondence with NVPTX a co-incidence.


https://github.com/llvm/llvm-project/pull/151225


More information about the llvm-commits mailing list