[LLVMdev] Is address space 1 reserved?

[Philip Reames]

On 01/07/2015 02:15 PM, Pete Cooper wrote:
>
>> On Jan 7, 2015, at 2:10 PM, Philip Reames <listmail at philipreames.com 
>> <mailto:listmail at philipreames.com>> wrote:
>>
>>
>> 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?
> It would be global metadata so can’t be dropped (or just isn’t right 
> now so its ok anyway)
>> - How do we merge such things in LTO?
> Thats a good point.
>> - Forward serialization?  It might be better to define the properties 
>> better than design a reasonable scheme.
> As is that.
>
> I think at the time I proposed metadata we didn’t have TTI or anything 
> else similar.  I would be happy to say that things like null ptr deref 
> are defined only for address space 0, and all other address spaces can 
> only be optimised if TTI supports it.  This means no TTI would default 
> to not optimizing anything other than address space 0 which I think is 
> good.
>
> You could also move all of the checks to TTI and define that NoTTI 
> gives an answer for address space 0 and ignores all others.  Then you 
> can just query TTI everywhere instead of special casing address space 
> 0 everywhere.
Either approach sounds fine; I have no opinion.  Volunteers? :)
>
> Pete
>>>
>>> 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://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/35ee11ec/attachment.html>