[LLVMdev] Is address space 1 reserved?

[Philip Reames]

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?

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.

>
> -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/bb80d335/attachment.html>