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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Alberto Barbaro via llvm-dev
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".


--
Thanks,
Jeremy


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Alberto Barbaro 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 <[hidden email]> 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".


--
Thanks,
Jeremy

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Alberto Barbaro via llvm-dev
Hi,

On Tue, Dec 4, 2018 at 5:00 PM David Blaikie <[hidden email]> 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.


--
Thanks,
Jeremy


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Alberto Barbaro 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:[hidden email]] On Behalf Of Jeremy Morse via llvm-dev
Sent: Tuesday, December 04, 2018 12:53 PM
To: [hidden email]
Cc: [hidden email]
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 <[hidden email]> 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.

 

 

--

Thanks,

Jeremy

 


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Alberto Barbaro via llvm-dev
In reply to this post by Alberto Barbaro via llvm-dev
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

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev