<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 01/07/2015 11:57 AM, Nick Lewycky
wrote:<br>
</div>
<blockquote
cite="mid:CADbEz-gwWv4SJH8XanZ95g1aujOsbO-Utf8QbRO0F+bQ_ky4Ow@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On 7 January 2015 at 11:25, Owen
Anderson <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:resistor@mac.com" target="_blank">resistor@mac.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto">
<div>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.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Oof. It was discussed when the patches to add addrspace
were being considered, and this is why we should've
written it down.</div>
<div><br>
</div>
<div>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?</div>
</div>
</div>
</div>
</blockquote>
From what I can tell, that flag combines two semantics:<br>
1) An object can live at null, null is dereferencable.<br>
2) Null checks should not be eliminated base on a previous
dereference of that location.<br>
<br>
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.<br>
<br>
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?<br>
0 - current meaning, default<br>
1-127 - reserved for custom extensions, no defined special semantics
in upstream<br>
128 - like address space zero, but null is dereferenceable<br>
129-255 - reserved for future generic usage<br>
256+ - reserved for generic target specific address spaces<br>
<br>
(This is strictly a strawman proposal; I have no attachment to this
suggestion.)<br>
<br>
<br>
<blockquote
cite="mid:CADbEz-gwWv4SJH8XanZ95g1aujOsbO-Utf8QbRO0F+bQ_ky4Ow@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto">
<div><br>
-Owen</div>
<div>
<div class="h5">
<div><br>
On Jan 7, 2015, at 1:18 PM, Philip Reames <<a
moz-do-not-send="true"
href="mailto:listmail@philipreames.com"
target="_blank">listmail@philipreames.com</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div> On the review for <a moz-do-not-send="true"
href="http://reviews.llvm.org/D6808"
target="_blank">http://reviews.llvm.org/D6808</a>,
<a moz-do-not-send="true"
href="http://reviews.llvm.org/p/majnemer/"
target="_blank">majnemer</a> commented that:<br>
<span>"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."<br>
<br>
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?<br>
<br>
The only address spaces with special meanings
I know of are:<br>
- 0 (the normal address space, null is not
dereferencable)<br>
- 256 - TLS, GS relative addressing<br>
- 257 - FS relative addressing<br>
<br>
Philip<br>
</span> </div>
</blockquote>
</div>
</div>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>LLVM Developers mailing list</span><br>
<span><a moz-do-not-send="true"
href="mailto:LLVMdev@cs.uiuc.edu"
target="_blank">LLVMdev@cs.uiuc.edu</a> <a
moz-do-not-send="true"
href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a></span><br>
<span><a moz-do-not-send="true"
href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev"
target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a></span><br>
</div>
</blockquote>
</div>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a moz-do-not-send="true"
href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>
<a moz-do-not-send="true"
href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a moz-do-not-send="true"
href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev"
target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>