I noticed a couple more small optimization opportunities when generating
DWARF expressions from the internal
DW_OP_LLVM_extract_bits_* operations:

* DW_OP_deref can be used, rather than DW_OP_deref_size, when the deref
size is the word size.

* If the bit offset is 0 and an unsigned extraction is desired, then
sometimes the shifting can be skipped entirely, or replaced with
DW_OP_and.

DW_OP_LLVM_extract_bits_zext and DW_OP_LLVM_extract_bits_sext can end up
emitting "DW_OP_constu 0; DW_OP_shr" when given certain arguments.
However, a shift by zero is not useful, and so it can be omitted.

The Ada front end can emit somewhat complicated DWARF expressions for
the offset of a field. While working in this area I found that I needed
DW_OP_rot (to implement a branch-free computation -- it looked more
difficult to add support for branching); and DW_OP_neg and DW_OP_abs
(just basic functionality).

The AArch64 zsub regs are scalable, so defined with a size of -1 (which
comes through as 65535). The RegisterSize is only 128, so code to try
and find overlapping regs of a z30_z31 in DwarfEmitter can crash on
trying to access out of range bits in a BitVector. Hexagon and x86 also
contain subregs with unknown sizes.

Ideally most of these would be scalable values but in the meantime add a
check that the register are small enough to overlap with the current
register size, to prevent us from crashing.

This fixes the issue reported on #153810.

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