<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Two thoughts:</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
1. I think that we should aim for regularity, to the extent possible, and so we should treat nonnull, align, etc. similarly w.r.t. to whether they produce poison or UB.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
2. I was thinking about the following last night, and it clarified for me why having an not_poison attribute makes sense and seems useful, and how poison/UB might affect things on a function-call boundary itself. Imagine that we had a fastcc lowering strategy
that took a pointer argument with an alignment attribute, followed by a suitably-small integer argument, and implemented a calling convention that passed both in the same register. If the pointer value might be poison, and thus violate the alignment attribute
(or might violate the alignment attribute otherwise and produce poison), then we can't implement this just by anding together the two values (to pass them in the one register). We need to mask off the low bits first. If the value can't be or generate poison,
and violating the alignment constraint produces UB, then the masking is not needed and we can just and together the two values (confident that the low bits will always be zero).</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
-Hal </div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="Signature">
<div class="BodyFragment"><font size="2"><span style="font-size:10pt;">
<div class="PlainText">Hal Finkel<br>
Lead, Compiler Technology and Programming Languages<br>
Leadership Computing Facility<br>
Argonne National Laboratory</div>
</span></font></div>
<div>
<div id="appendonsend"></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> llvm-dev <llvm-dev-bounces@lists.llvm.org> on behalf of Finkel, Hal J. via llvm-dev <llvm-dev@lists.llvm.org><br>
<b>Sent:</b> Wednesday, February 19, 2020 2:29 AM<br>
<b>To:</b> Doerfert, Johannes <johannesdoerfert@gmail.com>; Juneyoung Lee <juneyoung.lee@sf.snu.ac.kr><br>
<b>Cc:</b> llvm-dev <llvm-dev@lists.llvm.org>; Nuno Lopes <nuno.lopes@ist.utl.pt>; John Regehr <regehr@cs.utah.edu><br>
<b>Subject:</b> Re: [llvm-dev] The semantics of nonnull attribute</font>
<div> </div>
</div>
<div>
<div class="x_moz-cite-prefix">On 2/19/20 1:16 AM, Doerfert, Johannes via llvm-dev wrote:<br>
</div>
<blockquote type="cite">
<pre class="x_moz-quote-pre">On 02/19, Juneyoung Lee via llvm-dev wrote:
</pre>
<blockquote type="cite">
<pre class="x_moz-quote-pre">Hello,
</pre>
<blockquote type="cite">
<pre class="x_moz-quote-pre"> Would it be correct to resolve this by saying that dereferenceable(N)
*implies* not_poison? This would be helpful as a clarification of how
it all fits together.
</pre>
</blockquote>
<pre class="x_moz-quote-pre">Yes, I think it makes sense.
</pre>
</blockquote>
<pre class="x_moz-quote-pre">I don't we should do that.
Take the `gep inbounds` example:
char* foo(char *arg) {
return `gep inbounds %arg, -100`
}
Here it depends if we want to deduce the output is dereferenceable(100)
or not. If we do, we need dereferenceable to mean poison if violated, as
with nonnull, because it is derived from poison. Only if we don't derive
dereferenceable for the return value we can go for dereferenceable
violations are UB.</pre>
</blockquote>
<p><br>
</p>
<p>Can you please clarify what it means for the output of dereferenceable to be poison? If we tag a memory address as dereferenceable, is the optimizer free to insert a load of the address immediately following that? Or we need to see some other access (prior
to any thread synchronization?) to say that's valid?</p>
<p>Thanks again,</p>
<p>Hal<br>
</p>
<p><br>
</p>
<blockquote type="cite">
<pre class="x_moz-quote-pre">In the end, I think, it boils down to the question if there are
situations where violation of some attributes should be poison and
violation of others should be UB. If such situations exists it is
unclear to me what makes the UB/poison ones special.
</pre>
<blockquote type="cite">
<pre class="x_moz-quote-pre">On Wed, Feb 19, 2020 at 12:14 PM Nicolai Hähnle <a class="x_moz-txt-link-rfc2396E" href="mailto:nhaehnle@gmail.com"><nhaehnle@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre class="x_moz-quote-pre">On Wed, Feb 19, 2020 at 3:51 AM Juneyoung Lee via llvm-dev
<a class="x_moz-txt-link-rfc2396E" href="mailto:llvm-dev@lists.llvm.org"><llvm-dev@lists.llvm.org></a> wrote:
</pre>
<blockquote type="cite">
<pre class="x_moz-quote-pre">I think not_poison (Johannes's used keyword) makes sense. We can
</pre>
</blockquote>
<pre class="x_moz-quote-pre">simulate the original UB semantics by simply attaching it, as explained.
</pre>
<blockquote type="cite">
<pre class="x_moz-quote-pre">For the attributes other than nonnull, we may need more discussion;
</pre>
</blockquote>
<pre class="x_moz-quote-pre">align attribute seems to be okay with defining it as poison,
dereferenceable may need UB even without nonnull (because it needs to be
non-poison as shown Nuno's hoisting example).
For reference, the hoisting example was:
f(dereferenceable(4) %p) {
loop() {
%v = load %p
use(%v)
}
}
=>
f(dereferenceable(4) %p) {
%v = load %p
loop() {
use(%v)
}
}
Would it be correct to resolve this by saying that dereferenceable(N)
*implies* not_poison? This would be helpful as a clarification of how
it all fits together.
Cheers,
Nicolai
</pre>
</blockquote>
<pre class="x_moz-quote-pre">--
Juneyoung Lee
Software Foundation Lab, Seoul National University
</pre>
</blockquote>
<pre class="x_moz-quote-pre"></pre>
<blockquote type="cite">
<pre class="x_moz-quote-pre">_______________________________________________
LLVM Developers mailing list
<a class="x_moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="x_moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<pre class="x_moz-quote-pre"></pre>
<br>
<fieldset class="x_mimeAttachmentHeader"></fieldset>
<pre class="x_moz-quote-pre">_______________________________________________
LLVM Developers mailing list
<a class="x_moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="x_moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<p><br>
</p>
</div>
</div>
</div>
</body>
</html>