[llvm-dev] nullptr bit-value for DebugInfo in non-default address spaces (original) (raw)

David Blaikie via llvm-dev llvm-dev at lists.llvm.org
Tue Dec 4 09:00:26 PST 2018

I'm pretty sure the null pointer for address space zero is necessarily zero

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)

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/showbug.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>

More information about the llvm-dev mailing list