> On Jan 7, 2015, at 2:55 PM, Philip Reames <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. -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 <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 <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 <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/33141bf6/attachment.html>
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>
> On Jan 7, 2015, at 12:05 PM, Matt Arsenault <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 <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. 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 <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 <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 <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/20150107/fd64f27f/attachment.html>
> On Jan 7, 2015, at 3:10 PM, Philip Reames <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> > 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 <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 <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 <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/5e5fa648/attachment.html>
On Wed, Jan 7, 2015 at 12:10 PM, Philip Reames <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> > 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> 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. >I know of GPU-targeting compilers that use C++ as a frontend language. I unfortunately don't have anything to point you to though. -- Sean Silva> > > -Matt > > > > -Matt > > > > > On Jan 7, 2015, at 1:18 PM, Philip Reames <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 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 > > > > > > > _______________________________________________ > 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/20150107/c8a4ac0a/attachment.html>
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>