[LLVMdev] Is address space 1 reserved?

[Sahasrabuddhe, Sameer]

On 1/8/2015 1:55 AM, Philip Reames wrote:
>>>> 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?
>>
>> Yes, it would. I’ve always imagined this to a be a large undertaking 
>> though
> I'd agree on the scope, but it also seems fairly straight forward.  If 
> this becomes a serious issue, this seems like a workable approach.

This sounds similar to a problem we face in the HSAIL backend. NULL is 
not a constant in HSAIL, but an instruction that returns "a constant 
address that is guaranteed to be invalid for the given address space". 
The instruction will always return the same constant, so it can be 
stored and used in a comparison. So in HSAIL, zero is a valid address 
that is not required to coincide with NULL. It would be incorrect to say 
that "null is dereferenceable" or that an object "resides at null" just 
because its address is zero.

The LLVM IR has the symbolic constant "null", which is great, but the 
trouble is in the SelectionDAG where it gets replaced by a zero. If the 
SDNode were to retain a symbolic "null", that would be sufficient for 
the HSAIL backend to emit the appropriate instruction.

Sameer.

>>
>>>
>>> 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.
>>
>> There’s an AMD static C++ extension language, and a khronos draft for 
>> an OpenCL C++ kernel language which applies the same sort of 
>> restrictions and address spaces to C++ as OpenCL C has. Last time I 
>> looked at this I remember that C allows a non-zero null pointer 
>> value, but 0 must be implicitly converted to the correct null pointer 
>> value and the NULL macro will expand to this integer value. I don’t 
>> think the OpenCL C spec touches the issue of different NULL values 
>> for different address spaces, but does explicitly allow different 
>> sized pointers for each. I am less clear on what C++ requires, but 
>> C++11 4.10 says "A null pointer constant is an integral constant 
>> expression (5.19) prvalue of integer type that evaluates to zero or a 
>> prvalue of type std::nullptr_t."
>>
>>
>>>
>>>>
>>>> -Matt
>>>>
>>>>
>>>>>>
>>>>>> -Matt
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Jan 7, 2015, at 1:18 PM, Philip Reames 
>>>>>>> <listmail at philipreames.com <mailto: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 <mailto:LLVMdev at cs.uiuc.edu> 
>>>>>>>> http://llvm.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 <mailto:LLVMdev at cs.uiuc.edu> 
>>>>>>> http://llvm.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/20150108/e68b1232/attachment.html>