[LLVMdev] Is address space 1 reserved?

[Philip Reames]

On 01/07/2015 12:17 PM, Pete Cooper wrote:
>
>> On Jan 7, 2015, at 12:05 PM, Matt Arsenault <arsenm2 at gmail.com 
>> <mailto:arsenm2 at gmail.com>> 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.
> Actually, we had a similar discussion a while ago about this: 
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-August/064624.html
>
> In the link I gave, I proposed using global metadata to describe 
> address spaces.  Its useful, for example, to know that an address 
> space is always to constant memory, i.e., the CL model.
>
> I think later in the conversation we also thought about defining the 
> relationships between address spaces in a similar method to tbaa on 
> types.  Then you could do address space AA.
I'm a bit hesitant* to do this with metadata.  At least to start with, 
these seem like backend specific properties.  Why not introduce some 
hooks into Target or Subtarget with the appropriate queries?

* Reasons for hesitancy:
- Not sure these are purely optimizations - is dropping always legal?
- How do we merge such things in LTO?
- Forward serialization?  It might be better to define the properties 
better than design a reasonable scheme.
>
> Pete
>>
>> -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 <mailto: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/eda2150e/attachment.html>