[llvm-dev] nullptr bit-value for DebugInfo in non-default address spaces (original) (raw)
Friedman, Eli via llvm-dev llvm-dev at lists.llvm.org
Tue Dec 4 11:27:42 PST 2018
- Previous message: [llvm-dev] nullptr bit-value for DebugInfo in non-default address spaces
- Next message: [llvm-dev] Where's the optimiser gone (part 8): remainder calculated "by hand", not via call of __divmoddi4
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 12/4/2018 6:47 AM, Jeremy Morse via llvm-dev wrote:
Hi llvm-dev@,
It recently transpired that LLVM doesn't correctly preserve debugging information when null pointer constants are assigned to variables [0], with the debug records getting dropped by SelectionDAG. Fixing that [1] raises a few questions about the bit-value of null in different address spaces, so I'd like to ask: * Can we just assume that null is zero-valued for all address spaces?
It's not explicitly stated anywhere in LangRef, but in practice a ConstantPointerNull must have a zero bit-pattern in all address-spaces. Patch welcome if you want to modify LangRef.
Note that this might not match the C notion of a "null pointer"... LLVM optimizations for C library functions assume a ConstantPointerNull is in fact a null pointer in address-space zero, but otherwise it generally doesn't care. clang supports mapping a null pointer to other values.
-Eli
-- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
- Previous message: [llvm-dev] nullptr bit-value for DebugInfo in non-default address spaces
- Next message: [llvm-dev] Where's the optimiser gone (part 8): remainder calculated "by hand", not via call of __divmoddi4
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]