[LLVMdev] Is address space 1 reserved?

[Sean Silva]

On Wed, Jan 7, 2015 at 12:10 PM, Philip Reames <listmail at philipreames.com>
wrote:

>
> On 01/07/2015 12:05 PM, Matt Arsenault wrote:
>
>
>  On Jan 7, 2015, at 2:55 PM, Philip Reames <listmail at philipreames.com>
> wrote:
>
>
> On 01/07/2015 11:52 AM, Matt Arsenault wrote:
>
>
>  On Jan 7, 2015, at 2:25 PM, Owen Anderson <resistor at mac.com> wrote:
>
>  I'm not aware of any such restriction, and I know of several LLVM based
> systems that use address space 1 for something other than that.
>
> -Owen
>
>
>  Yes, this would be a problem for us. We use 1 for a normal address space
> where 0 is invalid. However, we also have a problem where some other
> address spaces do want 0 to be a valid address, which just sort of don’t
> work correctly now.
>
> If you have an example with a null in a non-0 address space being
> mishandled, please file a bug.  We'll fix them as we find them.
>
>
>  I think the problems aren’t so much that accessing 0 doesn’t work
> (although I imagine there are problems with that), but expectations of
> comparison with null. The main problem I’m aware of is comparisons with
> null pointers. The first global object in addrspace(3) will have the
> address of 0, so if a user does if (x != NULL), it will not behave as
> expected. For C I think this is supposed to be fixed by changing the value
> of NULL to -1, but I don’t think that is currently supported. That is also
> complicated because the null value is different for different address
> spaces, and I think the actual null pointer value must be 0 for C++. It
> doesn’t really turn up often in real code so I don’t think anybody has
> really spent time thinking about how to properly solve this.
>
> Just to make sure I'm interpreting this right: the problem is essentially
> that we hard code "null" to mean address 0 in all address spaces?  If we
> allowed the numeric value of null to be configurable per address space,
> would that resolve the issue at the LLVM IR level?
>
> Solving the frontend/language spec problem seems out of scope for LLVM,
> though probably not for clang.  Can you point me to a usage of C++ with
> non-zero address spaces?  I'd be curious to know what's happening in this
> space.
>

I know of GPU-targeting compilers that use C++ as a frontend language. I
unfortunately don't have anything to point you to though.

-- Sean Silva


>
>
>  -Matt
>
>
>
>  -Matt
>
>
>
>
> On Jan 7, 2015, at 1:18 PM, Philip Reames <listmail at philipreames.com>
> wrote:
>
>   On the review for http://reviews.llvm.org/D6808, majnemer
> <http://reviews.llvm.org/p/majnemer/> commented that:
> "Address space 1 has a special meaning in LLVM, it's identical to address
> space 0 except for the fact that "null" may be dereferenced. You might want
> to consider a different address space."
>
> This is the first I've heard of this and I can't find any documentation
> about it being reserved, either in general, or specifically for x86.  Can
> anyone clarify?
>
> The only address spaces with special meanings I know of are:
> - 0 (the normal address space, null is not dereferencable)
> - 256 - TLS, GS relative addressing
> - 257 - FS relative addressing
>
> Philip
>
>  _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>  _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150107/c8a4ac0a/attachment.html>