[LLVMdev] Is address space 1 reserved?

[Philip Reames]

On 01/07/2015 12:22 PM, Matt Arsenault wrote:
>
>> On Jan 7, 2015, at 3:10 PM, Philip Reames <listmail at philipreames.com 
>> <mailto: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 <mailto: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 
>>>>>> <mailto: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?
>
> 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.
>
>>
>> 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
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150107/dc61f5ab/attachment.html>