[llvm-dev] nullptr bit-value for DebugInfo in non-default address spaces

[David Blaikie via llvm-dev]

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>