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

[via llvm-dev]

I suspect you would need to implement some new target hook that would report back the nullptr value for a given address space.  The default implementation would return zero.  AMDGPU (and possibly others) would implement the hook to return the appropriate value.
--paulr

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Jeremy Morse via llvm-dev
Sent: Tuesday, December 04, 2018 12:53 PM
To: dblaikie at gmail.com
Cc: llvm-dev at lists.llvm.org
Subject: Re: [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<mailto: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/45af8e89/attachment.html>