llvm dev - Nov 2013 - [LLVMdev] Null pointers with a non-0 representation

I feel a bit silly asking this, but here goes.

The C spec  does not require the null pointer to be implemented as an integer
with the 0 bit-pattern. The implementation may arbitrarily choose any other
(integer, but not necessarily) representation, as long as it's distinct from
any legal pointer. The only requirement is that casting an integer 0 to a
pointer type results in a null pointer.
LLVM IR appears to have similar the casting behavior.  That is, if I try to
create a pointer with integer value 0 (e.g. by constructing an inttoptr constant
expression with a i32 0 argument), it gets immediately folded into a null
pointer constant. Furthermore, a PtrToInt from a null pointer results in 0
(which is even "stricter" than the C spec.)

So, that raises a few question:

a)      Are those the desired semantics? I guess if clang generates this kind of
IntToPtr instructions (as opposed to directly resolving the cast to a null
pointer) this is unavoidable. But otherwise, why does LLVM treat null pointers
and pointers with the integer value 0 as equivalent?
It's completely natural for most platforms, but isn't necessarily the
right thing to do.

b)      Assuming this is really desirable, should the fact that casting an
integer 0 to a pointer type results in a null pointer be documented in the
langref (as part of the inttoptr/ptrtoint documentation)? Or is it too
"low-level"?

c)       Let's say I want to create a pointer with the numeric value 0,
distinct from the null pointer, because 0 really does represent a valid pointer
on my platform. Should this possible at the IR level? If it should be, then how?

Anyone has any inputs, except laughing me out of the (virtual) room? :-)

Thanks,
   Michael
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131117/98e4e7e3/attachment.html>

I ran into the same problem in OpenCL with Local/Private address spaces and I
believe it was discussed here in the past. So I would suggest looking through
the archives as I believe some of your questions are answered there.
This post might be a good starting point:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/044101.html

Also the SPIR provisional spec as of last November deals with this issue if I
remember correctly, so maybe you can discuss with Boaz Ouriel if he is still at
Intel Israel about how they went about handling this problem, or look at the
SPIR related posts from last year.

Hope this helps,
Micah

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Kuperstein, Michael M
Sent: Sunday, November 17, 2013 1:15 AM
To: LLVMdev at cs.uiuc.edu
Subject: [LLVMdev] Null pointers with a non-0 representation

I feel a bit silly asking this, but here goes.

The C spec  does not require the null pointer to be implemented as an integer
with the 0 bit-pattern. The implementation may arbitrarily choose any other
(integer, but not necessarily) representation, as long as it's distinct from
any legal pointer. The only requirement is that casting an integer 0 to a
pointer type results in a null pointer.
LLVM IR appears to have similar the casting behavior.  That is, if I try to
create a pointer with integer value 0 (e.g. by constructing an inttoptr constant
expression with a i32 0 argument), it gets immediately folded into a null
pointer constant. Furthermore, a PtrToInt from a null pointer results in 0
(which is even "stricter" than the C spec.)

So, that raises a few question:

a)      Are those the desired semantics? I guess if clang generates this kind of
IntToPtr instructions (as opposed to directly resolving the cast to a null
pointer) this is unavoidable. But otherwise, why does LLVM treat null pointers
and pointers with the integer value 0 as equivalent?
It's completely natural for most platforms, but isn't necessarily the
right thing to do.

b)      Assuming this is really desirable, should the fact that casting an
integer 0 to a pointer type results in a null pointer be documented in the
langref (as part of the inttoptr/ptrtoint documentation)? Or is it too
"low-level"?

c)       Let's say I want to create a pointer with the numeric value 0,
distinct from the null pointer, because 0 really does represent a valid pointer
on my platform. Should this possible at the IR level? If it should be, then how?

Anyone has any inputs, except laughing me out of the (virtual) room? :-)

Thanks,
   Michael

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131117/6ea057e6/attachment.html>

Hi Micah,

Thanks a lot for the reference.
Unfortunately, it looks like the discussion there is dealing with a somewhat
different issue - modeling OpenCL address spaces. It's true that the null
pointer issue may arise in a similar context (e.g. null pointers in different
address spaces may have different internal representations), but it's not
entirely related. Or have I missed something in the thread?

Thanks,
  Michael

From: Micah Villmow [mailto:micah.villmow at smachines.com]
Sent: Sunday, November 17, 2013 11:42
To: Kuperstein, Michael M; LLVMdev at cs.uiuc.edu
Subject: RE: Null pointers with a non-0 representation

I ran into the same problem in OpenCL with Local/Private address spaces and I
believe it was discussed here in the past. So I would suggest looking through
the archives as I believe some of your questions are answered there.
This post might be a good starting point:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/044101.html

Also the SPIR provisional spec as of last November deals with this issue if I
remember correctly, so maybe you can discuss with Boaz Ouriel if he is still at
Intel Israel about how they went about handling this problem, or look at the
SPIR related posts from last year.

Hope this helps,
Micah

From: llvmdev-bounces at cs.uiuc.edu<mailto:llvmdev-bounces at
cs.uiuc.edu> [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Kuperstein,
Michael M
Sent: Sunday, November 17, 2013 1:15 AM
To: LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu>
Subject: [LLVMdev] Null pointers with a non-0 representation

I feel a bit silly asking this, but here goes.

The C spec  does not require the null pointer to be implemented as an integer
with the 0 bit-pattern. The implementation may arbitrarily choose any other
(integer, but not necessarily) representation, as long as it's distinct from
any legal pointer. The only requirement is that casting an integer 0 to a
pointer type results in a null pointer.
LLVM IR appears to have similar the casting behavior.  That is, if I try to
create a pointer with integer value 0 (e.g. by constructing an inttoptr constant
expression with a i32 0 argument), it gets immediately folded into a null
pointer constant. Furthermore, a PtrToInt from a null pointer results in 0
(which is even "stricter" than the C spec.)

So, that raises a few question:

a)      Are those the desired semantics? I guess if clang generates this kind of
IntToPtr instructions (as opposed to directly resolving the cast to a null
pointer) this is unavoidable. But otherwise, why does LLVM treat null pointers
and pointers with the integer value 0 as equivalent?
It's completely natural for most platforms, but isn't necessarily the
right thing to do.

b)      Assuming this is really desirable, should the fact that casting an
integer 0 to a pointer type results in a null pointer be documented in the
langref (as part of the inttoptr/ptrtoint documentation)? Or is it too
"low-level"?

c)       Let's say I want to create a pointer with the numeric value 0,
distinct from the null pointer, because 0 really does represent a valid pointer
on my platform. Should this possible at the IR level? If it should be, then how?

Anyone has any inputs, except laughing me out of the (virtual) room? :-)

Thanks,
   Michael

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131117/deeb9613/attachment.html>