On 01/07/2015 11:57 AM, Nick Lewycky wrote:
> On 7 January 2015 at 11:25, Owen Anderson > 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.
> Oof. It was discussed when the patches to add addrspace were being
> considered, and this is why we should've written it down.
> It would be nice to have an addrspace that does mean "same as
> addrspace(0) except that null may be dereferenceable", and to attach
> that to -fno-delete-null-pointer-checks. Any ideas for what that
> addrspace should be?
From what I can tell, that flag combines two semantics:
1) An object can live at null, null is dereferencable.
2) Null checks should not be eliminated base on a previous dereference
of that location.
I suspect most usage is for the second, probably for security mitigation
in legacy programs. Using an address space seems like a great solution
for a use case which actually requires both, but I'd be tempted to try
something else for security mitigation. I wonder how far we could get
performance wise by null checking *every* access and then optimizing
them away? This is strictly stronger.
Returning from that tangent, I'm not arguing against the reservation of
such an address space. Since we seem to have precedent for larger
numbers meaning reserved things, why don't we document the following?
0 - current meaning, default
1-127 - reserved for custom extensions, no defined special semantics in
128 - like address space zero, but null is dereferenceable
129-255 - reserved for future generic usage
256+ - reserved for generic target specific address spaces
(This is strictly a strawman proposal; I have no attachment to this
> On Jan 7, 2015, at 1:18 PM, Philip Reames
> > wrote:
>> On the review for http://reviews.llvm.org/D6808,
>> "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
>> LLVM Developers mailing list
>> [email protected]
> LLVM Developers mailing list
> [email protected]