Jeremy Morse via llvm-dev
2018-Dec-04 14:47 UTC
[llvm-dev] nullptr bit-value for DebugInfo in non-default address spaces
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? * If not, are there APIs available for determining an address spaces' null-value? What's permissible / disallowed for address spaces is unclear to me. Various comments around the code base suggest that nullptr is always zero for address space zero; I'm not aware of rules for other address spaces. Without further information, the current solution is to have non-zero address space nulls marked as "optimized out". [0] https://bugs.llvm.org/show_bug.cgi?id=39787 [1] https://reviews.llvm.org/D55227 -- Thanks, Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181204/0be7b8bc/attachment.html>
David Blaikie via llvm-dev
2018-Dec-04 17:00 UTC
[llvm-dev] nullptr bit-value for DebugInfo in non-default address spaces
I'm pretty sure the null pointer for address space zero is necessarily zero - but off-hand don't know if/where that's specified, hopefully someone else can cchime in with that info. If that's the only guarantee (& there's no guarantee on non-zero address space's null pointer representation) is that sufficient to address some cases you're dealing with, or is the address space not known at the point where you're trying to make this decision? (ie: you could only use zero if you know all address spaces have zero null pointers) - Dave On Tue, Dec 4, 2018 at 6:48 AM Jeremy Morse via llvm-dev < llvm-dev at lists.llvm.org> 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? > * If not, are there APIs available for determining an address spaces' > null-value? > > What's permissible / disallowed for address spaces is unclear to me. > Various comments around the code base suggest that nullptr is always zero > for address space zero; I'm not aware of rules for other address spaces. > Without further information, the current solution is to have non-zero > address space nulls marked as "optimized out". > > [0] https://bugs.llvm.org/show_bug.cgi?id=39787 > [1] https://reviews.llvm.org/D55227 > > -- > Thanks, > Jeremy > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181204/fa05260e/attachment.html>
Jeremy Morse via llvm-dev
2018-Dec-04 17:52 UTC
[llvm-dev] nullptr bit-value for DebugInfo in non-default address spaces
Hi, On Tue, Dec 4, 2018 at 5:00 PM David Blaikie <dblaikie at gmail.com> wrote:> If that's the only guarantee (& there's no guarantee on non-zero address > space's null pointer representation) is that sufficient to address some > cases you're dealing with, or is the address space not known at the point > where you're trying to make this decision? (ie: you could only use zero if > you know all address spaces have zero null pointers) >The address space is known at the relevant point, and the "zero valued in address space zero" guarantee is sufficient for the overwhelmingly common case. However I'd prefer completeness, and it seemed to me that there must be some way of determining a null bit-value from an address space number. I guess a revised question would be: given that in this AMDGPU test [0] some null pointer constants eventually get lowered to be valued "-1", how would I go about doing the same for the corresponding debug info? Clearly that information is available somewhere, I need guidance however on where to look. [0] https://github.com/llvm-mirror/llvm/blob/5018f6ea8fcd1c655d36a2ae1900e0ccee906b96/test/CodeGen/AMDGPU/nullptr.ll#L100 -- Thanks, Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181204/1abbda93/attachment.html>
Friedman, Eli via llvm-dev
2018-Dec-04 19:27 UTC
[llvm-dev] nullptr bit-value for DebugInfo in non-default address spaces
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
Possibly Parallel Threads
- Nouveau nullptr on NVIDIA NVA8
- Is it time to allow StringRef to be constructed from nullptr?
- Is it time to allow StringRef to be constructed from nullptr?
- Is it time to allow StringRef to be constructed from nullptr?
- problem with subscriptions file version 1.0.1