Backends like NVPTX use -1 to indicate `true` and 0 to indicate `false` for boolean values. Machine instruction `#DBG_VALUE` also uses -1 to indicate a `true` boolean constant. However, during the DWARF generation, booleans are treated as unsigned variables, and the debug_loc expression, like `DW_OP_lit0; DW_OP_not` is emitted for the `true` value. This leads to the debugger printing `255` instead of `true` for constant boolean variables. This change emits `DW_OP_lit1` instead of `DW_OP_lit0; DW_OP_not`.
Reverts llvm/llvm-project#155539
Failing on buildbots with:
```
Step 7 (test-build-stage1-unified-tree-check-all) failure: test (failure)
******************** TEST 'LLVM :: DebugInfo/debug-bool-const-location.ll' FAILED ********************
Exit Code: 1
Command Output (stderr):
--
/home/buildbots/llvm-external-buildbots/workers/ppc64le-lld-multistage-test/ppc64le-lld-multistage-test/build/stage1/bin/llc /home/buildbots/llvm-external-buildbots/workers/ppc64le-lld-multistage-test/ppc64le-lld-multistage-test/llvm-project/llvm/test/DebugInfo/debug-bool-const-location.ll -O3 -filetype=obj -o - | /home/buildbots/llvm-external-buildbots/workers/ppc64le-lld-multistage-test/ppc64le-lld-multistage-test/build/stage1/bin/llvm-dwarfdump - | /home/buildbots/llvm-external-buildbots/workers/ppc64le-lld-multistage-test/ppc64le-lld-multistage-test/build/stage1/bin/FileCheck /home/buildbots/llvm-external-buildbots/workers/ppc64le-lld-multistage-test/ppc64le-lld-multistage-test/llvm-project/llvm/test/DebugInfo/debug-bool-const-location.ll # RUN: at line 2
+ /home/buildbots/llvm-external-buildbots/workers/ppc64le-lld-multistage-test/ppc64le-lld-multistage-test/build/stage1/bin/llc /home/buildbots/llvm-external-buildbots/workers/ppc64le-lld-multistage-test/ppc64le-lld-multistage-test/llvm-project/llvm/test/DebugInfo/debug-bool-const-location.ll -O3 -filetype=obj -o -
+ /home/buildbots/llvm-external-buildbots/workers/ppc64le-lld-multistage-test/ppc64le-lld-multistage-test/build/stage1/bin/llvm-dwarfdump -
+ /home/buildbots/llvm-external-buildbots/workers/ppc64le-lld-multistage-test/ppc64le-lld-multistage-test/build/stage1/bin/FileCheck /home/buildbots/llvm-external-buildbots/workers/ppc64le-lld-multistage-test/ppc64le-lld-multistage-test/llvm-project/llvm/test/DebugInfo/debug-bool-const-location.ll
/home/buildbots/llvm-external-buildbots/workers/ppc64le-lld-multistage-test/ppc64le-lld-multistage-test/llvm-project/llvm/test/DebugInfo/debug-bool-const-location.ll:7:10: error: CHECK: expected string not found in input
; CHECK: {{.*}} DW_OP_lit0
^
<stdin>:27:54: note: scanning from here
[0x0000000000000018, 0x0000000000000020): DW_OP_lit1, DW_OP_stack_value
^
<stdin>:28:41: note: possible intended match here
[0x0000000000000020, 0x0000000000000034): DW_OP_reg3 X3)
^
Input file: <stdin>
Check file: /home/buildbots/llvm-external-buildbots/workers/ppc64le-lld-multistage-test/ppc64le-lld-multistage-test/llvm-project/llvm/test/DebugInfo/debug-bool-const-location.ll
-dump-input=help explains the following input dump.
Input was:
<<<<<<
.
.
.
22: DW_AT_decl_line (5)
23: DW_AT_external (true)
24:
25: 0x0000003f: DW_TAG_variable
26: DW_AT_location (0x00000000:
27: [0x0000000000000018, 0x0000000000000020): DW_OP_lit1, DW_OP_stack_value
check:7'0 X~~~~~~~~~~~~~~~~~~~ error: no match found
28: [0x0000000000000020, 0x0000000000000034): DW_OP_reg3 X3)
check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
check:7'1 ? possible intended match
29: DW_AT_name ("arg")
check:7'0 ~~~~~~~~~~~~~~~~~~~~
30: DW_AT_decl_file ("test")
check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~
31: DW_AT_decl_line (5)
check:7'0 ~~~~~~~~~~~~~~~~~~~~~
32: DW_AT_type (0x0000004f "bool")
check:7'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
33:
check:7'0 ~
.
```
Backends like NVPTX use -1 to indicate `true` and 0 to indicate `false` for boolean values. Machine instruction `#DBG_VALUE` also uses -1 to indicate a `true` boolean constant. However, during the DWARF generation, booleans are treated as unsigned variables, and the debug_loc expression, like `DW_OP_lit0; DW_OP_not` is emitted for the `true` value. This leads to the debugger printing `255` instead of `true` for constant boolean variables. This change emits `DW_OP_lit1` instead of `DW_OP_lot0; DW_OP_not`.
NVPTX needs to be able to get the Dwarf register number for a virtual register. The interface we have for this today is on MCRegisterInfo and take a MCRegister argument. It shouldn't be legal to convert a Register containing a virtual register to an MCRegister. This patch adds a getDwarfRegNumForVirtReg function that takes a Register to TRI and splits the NVPTX override of getDwarfRegNum.
This patch adds support for encoding PTX registers for DWARF, using the encoding supported by nvcc and cuda-gcc. There are some other features still needed for proper register debugging that this patch does not address, such as DW_AT_address_class. This PR is stacked on: https://github.com/llvm/llvm-project/pull/109494
The register encoding used by NVPTX and cuda-gdb basically use strings encoded as numbers. They are always within 64-bits, but typically outside of 32-bits, since they often need at least 5 characters. This patch changes the signature of `MCRegisterInfo::getDwarfRegNum` and some related data structures to use 64-bit numbers to accommodate encodings like this. Additionally, `MCRegisterInfo::getDwarfRegNum` is marked as virtual, so that targets with peculiar dwarf register mapping schemes (such as NVPTX) can override its behavior. I originally tried to do a broader switch to 64-bit types for registers, but it caused many problems. There are various places in code generation where registers are not just treated as 32-bit numbers, but also treat certain bit offsets as flags. So I limited the change as much as possible to just the output of `getDwarfRegNum`. Keeping the types used by `DwarfLLVMRegPair` as unsigned preserves the current behaviors. The only way to give a 64-bit output from `getDwarfRegNum` that actually needs more than 32-bits is to override `getDwarfRegNum` and provide an implementation that sidesteps the use of the `DwarfLLVMRegPair` maps defined in tablegen files. First layer of stack supporting: https://github.com/llvm/llvm-project/pull/109495
Using DW_OP_deref can result in the debugger reading past the end of an object into inaccessible memory, causing an error. Instead use DW_OP_deref_size to make sure we don't read any bytes beyond what we need to.
This operation extracts a number of bits at a given offset and sign or zero extends them, which is done by emitting it as a left shift followed by a right shift. This is being added for use in clang for C++ structured bindings of bitfields that have offset or size that aren't a byte multiple. A new operation is being added, instead of shifts being used directly, as it makes correctly handling it in optimisations (which will be done in a later patch) much easier.
With D149881, we converted EntryValue MachineFunction table entries into `DbgVariables` initialized by a "DbgValue" intrinsic, which can only handle a single, non-fragment DIExpression. However, it is desirable to handle variables with multiple fragments and DIExpressions. To do this, we expand the `DbgVariable` class to handle the EntryValue case. This class can already operate under three different "modes" (stack slot, unchanging location described by a dbg value, changing location described by a loc list). A fourth case is added as a separate class entirely, but a subsequent patch should redesign `DbgVariable` with four subclasses in order to make the code more readable. This patch also exposed a bug in the `beginEntryValueExpression` function, which was not initializing the `LocationFlags` properly. Note how the `finalizeEntryValue` function resets that flag. We fix this bug here, as testing this changing in isolation would be tricky. Differential Revision: https://reviews.llvm.org/D158458
salvageDebugInfo is a function that allows us to reatin debug info for instructions that have been optimized out. Currently, it doesn't support salvaging the debug information from icmp instrcutions, but DWARF expressions can emulate an icmp by using the DWARF conditional expressions. This patch adds support for salvaging debug information from icmp instructions. Differential Revision: https://reviews.llvm.org/D150216