<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 18, 2016 at 8:24 PM, Flamedoge via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="">>>><br><div style="font-size:12.8px">In this particular case, since the def of %x in the caller is also an argument, we could propagate it to the def directly, e.g.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><span style="color:rgb(0,0,0);font-family:helvetica,arial,sans-serif;font-size:16px">define i1 @foo(i32* nonnull %x) {</span><br style="color:rgb(0,0,0);font-family:helvetica,arial,sans-serif;font-size:16px"><span style="color:rgb(0,0,0);font-family:helvetica,arial,sans-serif;font-size:16px"> %y.i = load i32, i32* %x ; inlined, still known to be nonnull</span></div><div style="font-size:12.8px"><span style="color:rgb(0,0,0);font-family:helvetica,arial,sans-serif;font-size:16px">>>></span></div></span><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;font-size:13.3333px"><br>For propagation of non-nullity to the argument, don't you need value propagation or backward all dataflow analysis?</span></div></blockquote><div><br></div><div><br></div><div>You need CDEQ, and need to check that the instruction and the call site are part of the same CDEQ set. This means they have the same set of control dependences.</div><div>With that, if the call site either dominates or post-dominates the def, you are fine, since you are guaranteed it either must execute the callsite first (if the callsite dominates it), or all paths to exit go through the callsite anyway (and thus, it must be non-null)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;font-size:13.3333px">IE. </span></div><div><span style="color:rgb(0,0,0);font-family:helvetica,arial,sans-serif;font-size:16px">define i1 @foo(i32* %x)</span> </div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;font-size:13.3333px"><br>if (%x != NULL)<br>{<br> </span><span style="color:rgb(0,0,0);font-family:helvetica,arial,sans-serif;font-size:16px">%y.i = load i32, i32* %x ; inlined</span><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;font-size:13.3333px"><br>}</span></div><div><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;font-size:13.3333px">// do something else with %x where it can still be null<br>It wouldn't be correct to make foo's argument non-null if callsite was guarded.</span></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 16, 2016 at 4:07 PM, Michael Kuperstein via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Fri, Dec 16, 2016 at 11:49 AM, Philip Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"><span class="m_-201567639833815211m_2993239186205058601gmail-">
<p><br>
</p>
<br>
<div class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151moz-cite-prefix">On 12/16/2016 11:37 AM, Michael
Kuperstein wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Calling an instruction a "source" is basically
another way to say "we can't dataflow through this".
<div><br>
<div>What I'm trying to say is that this is not really a
property of the instruction type.</div>
<div>I agree we should be adding annotations sparingly - that
is, we should not annotate something we can infer. But
that's a semantic property, so I don't really see why that
means we should prohibit annotating certain instructions on
the syntactic level.</div>
</div>
</div>
</blockquote></span>
I'm not opposed to this per se, but I see it as a slippery slope
argument. One of the foundational design principles of LLVM is that
analysis results are inferred from the IR, not part of the IR. This
decision is hugely important for stability and extensibility of the
framework.</div></blockquote><div> </div></span><div>Agreed.</div><span><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">If we ever got to the day where we were putting !range
on an add instruction as part of a transform pass, that would
clearly be several steps too far.</div></blockquote><div><br></div></span><div>Yes.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><span class="m_-201567639833815211m_2993239186205058601gmail-"><br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Admittedly, the only example I have in mind right now is
the one under discussion above - if we have:</div>
<div><br>
</div>
<div>%p = select i1 %a, i8* %x, i8 *y</div>
<div>call void foo(i8* nonnull %p)</div>
<div><br>
</div>
<div>Then after inlining foo, we lose the non-null information
for %p unless we annotate it - and we can't propagate it
through the select. The same would happen for a phi, <br>
</div>
</div>
</blockquote></span>
Are there cases where we loose information by inlining this
example? Yes. Are they common? I don't know. In particular, if
foo contains an unconditional load from %p, we don't actually loose
any information by inlining. Similarly, we can frequently infer the
non-null fact from another source.<br>
<br></div></blockquote><div><br></div></span><div>If foo contains an unconditional load from %p, then the original nonnull attribute was also redundant. I'm assuming we're talking about cases where the original attribute contained information not available elsewhere.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
Just to be clear, I want to spell out a distinction between having
metadata available for frontend annotation and having the optimizer
itself introduce metadata. The former is a much easier request
because it implies a much smaller maintenance burden. </div></blockquote><div><br></div></span><div>The optimizer can already do this, using assumes. By allowing !nonnull on more instructions we wouldn't actually be letting the optimizer do something it couldn't do before, we'd just make the representation more uniform. But I understand the point of view that it also makes potentially undesirable optimizer behavior simpler and thus more appealing.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">If we screw
something up (compile time say), then only the frontend that cared
bears the cost. If we start having the optimizer itself introduce
metadata (or assumes, etc..), then the justification has to
sufficient for *all* frontends and use cases. In practice, that's
going to be a much higher bar to clear.</div></blockquote><div><br></div></span><div>Maybe. In any case, I don't feel strongly about this, I was just trying to understand the rationale.</div><div><div class="m_-201567639833815211h5"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><div><div class="m_-201567639833815211m_2993239186205058601gmail-h5"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Dec 16, 2016 at 11:25 AM,
Philip Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p>The general idea to date has been only "sources" get
annotations. If there's something we fundamentally
*can't* analyze through, that's where we annotate. We
try not to use annotations for places where we could
have but didn't. </p>
e.g. call metadata/attributes allow us to model external
calls, load metadata allow us to model frontend
knowledge of external memory locations, etc..
<div>
<div class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151h5"><br>
<br>
<div class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151m_2027015015759923768moz-cite-prefix">On
12/16/2016 11:03 AM, Michael Kuperstein via
llvm-dev wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">By the way, I've been wondering -
why can we only attach !nonnull and !range to
loads (for both) and call/invoke (for !range)?
<div><br>
</div>
<div>I mean, those are all instructions you
can't do dataflow through - intraprocedurally,
w/o memoryssa - but why only these
instructions? Why not allow annotating any
pointer def with !nonnull and any integer def
with !range?</div>
<div>Sure, that's redundant w.r.t llvm.assume,
but so are the existing annotations.</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Dec 14, 2016 at
11:20 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank"></a><a class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151moz-txt-link-abbreviated" href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)"><br>
<br>
<hr id="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151m_2027015015759923768m_8813124120249439675zwchr">
<blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:helvetica,arial,sans-serif;font-size:12pt"><b>From:
</b>"Michael Kuperstein" <<a href="mailto:michael.kuperstein@gmail.com" target="_blank"></a><a class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151moz-txt-link-abbreviated" href="mailto:michael.kuperstein@gmail.com" target="_blank">michael.kuperstein@gmail.com</a>><br>
<b>To: </b>"Hal Finkel" <<a href="mailto:hfinkel@anl.gov" target="_blank"></a><a class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151moz-txt-link-abbreviated" href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>><br>
<b>Cc: </b>"Sanjay Patel" <<a class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151m_2027015015759923768moz-txt-link-abbreviated" href="mailto:spatel@rotateright.com" target="_blank"></a><a class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151moz-txt-link-abbreviated" href="mailto:spatel@rotateright.com" target="_blank">spatel@rotateright.com</a>>,
"llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank"></a><a class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>,
"Michael Kuperstein" <<a href="mailto:mkuper@google.com" target="_blank"></a><a class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151moz-txt-link-abbreviated" href="mailto:mkuper@google.com" target="_blank">mkuper@google.com</a>><br>
<b>Sent: </b>Thursday, December 15,
2016 1:13:07 AM<span><br>
<b>Subject: </b>Re: [llvm-dev]
analysis based on nonnull attribute<br>
<br>
</span><span>
<div dir="ltr">I think what Sanjay
is getting at is that it's not an
integer, it's still a pointer -
but it's not clear where
information about non-nullness of
the pointer should be propagated
to.
<div><br>
<div>In this particular case,
since the def of %x in the
caller is also an argument, we
could propagate it to the def
directly, e.g.</div>
<div><br>
</div>
<div><span style="color:rgb(0,0,0);font-family:helvetica,arial,sans-serif;font-size:16px">define
i1 @foo(i32* nonnull %x) {</span><br style="color:rgb(0,0,0);font-family:helvetica,arial,sans-serif;font-size:16px">
<span style="color:rgb(0,0,0);font-family:helvetica,arial,sans-serif;font-size:16px">
%y.i = load i32, i32* %x ;
inlined, still known to be
nonnull</span><br>
</div>
<div><span style="color:rgb(0,0,0);font-family:helvetica,arial,sans-serif;font-size:16px"><br>
</span></div>
And if the def of %x was a load,
we could use !nonnull. But I'm
not sure what we can do in the
general case (say, %x =
select...).</div>
<div id="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151m_2027015015759923768m_8813124120249439675DWT59679">The
best I can think of is
generating an llvm.assume for
the condition.</div>
</div>
</span></blockquote>
True. In this case, the preferred thing
would be to add the nonnull attribute to
the caller's parameter. Adding
llvm.assume is indeed a general
solution.<span class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151m_2027015015759923768HOEnZb"><font color="#888888"><br>
<br>
-Hal</font></span>
<div>
<div class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151m_2027015015759923768h5"><br>
<blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:helvetica,arial,sans-serif;font-size:12pt">
<div dir="ltr">
<div><br>
</div>
<div>Michael</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 14
December 2016 at 14:05, Hal
Finkel via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank"></a><a class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)"><br>
<hr id="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151m_2027015015759923768m_8813124120249439675m_-7730040808428572051m_-2858323345671407143zwchr">
<blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:helvetica,arial,sans-serif;font-size:12pt"><b>From:
</b>"Sanjay Patel"
<<a class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151m_2027015015759923768moz-txt-link-abbreviated" href="mailto:spatel@rotateright.com" target="_blank"></a><a class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151moz-txt-link-abbreviated" href="mailto:spatel@rotateright.com" target="_blank">spatel@rotateright.com</a>><br>
<b>To: </b>"Hal
Finkel" <<a class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151m_2027015015759923768moz-txt-link-abbreviated" href="mailto:hfinkel@anl.gov" target="_blank"></a><a class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151moz-txt-link-abbreviated" href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>><br>
<b>Cc: </b>"llvm-dev"
<<a class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151m_2027015015759923768moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank"></a><a class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>Sent: </b>Wednesday,
December 14, 2016
4:03:40 PM<br>
<b>Subject: </b>Re:
[llvm-dev] analysis
based on nonnull
attribute
<div>
<div class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151m_2027015015759923768m_8813124120249439675m_-7730040808428572051h5"><br>
<br>
<div dir="ltr"><br>
<div id="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151m_2027015015759923768m_8813124120249439675m_-7730040808428572051m_-2858323345671407143DWT51043" class="gmail_extra"><br>
<div class="gmail_quote">On
Wed, Dec 14,
2016 at 2:51
PM, Hal Finkel
<span dir="ltr"><<a class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151m_2027015015759923768moz-txt-link-abbreviated" href="mailto:hfinkel@anl.gov" target="_blank"></a><a class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151moz-txt-link-abbreviated" href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><br>
<div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)"><br>
<hr id="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151m_2027015015759923768m_8813124120249439675m_-7730040808428572051m_-2858323345671407143gmail-m_3630810500302298505zwchr">
<blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:helvetica,arial,sans-serif;font-size:12pt"><b>From:
</b>"Sanjay
Patel via
llvm-dev" <<a class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151m_2027015015759923768moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank"></a><a class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>To: </b>"llvm-dev"
<<a class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151m_2027015015759923768moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank"></a><a class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>Sent: </b>Wednesday,
December 14,
2016 3:47:03
PM<br>
<b>Subject: </b>[llvm-dev]
analysis based
on nonnull
attribute<span class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151m_2027015015759923768m_8813124120249439675m_-7730040808428572051m_-2858323345671407143gmail-"><br>
<br>
<div id="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151m_2027015015759923768m_8813124120249439675m_-7730040808428572051m_-2858323345671407143gmail-m_3630810500302298505DWT50626" dir="ltr">Does
the nonnull
parameter
attribute give
us information
about
subsequent
uses of that
value outside
of the
function that
has the
attribute? <br>
</div>
</span></blockquote>
Yes. We're
guaranteeing
that we never
pass a null
value for the
argument, so
that
information
can be used to
optimize the
caller as
well.</div>
</div>
</blockquote>
<div><br>
</div>
<div>Thanks! I
don't know if
that will
actually solve
our
sub-optimal
output for
dyn_cast (!),
but it might
help...<br>
<a class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151m_2027015015759923768moz-txt-link-freetext" href="https://llvm.org/bugs/show_" target="_blank"></a><a class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151moz-txt-link-freetext" href="https://llvm.org/bugs/show_" target="_blank">https://llvm.org/bugs/show_</a>bug<wbr>.cgi?id=28430<br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)"><span class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151m_2027015015759923768m_8813124120249439675m_-7730040808428572051m_-2858323345671407143gmail-"><br>
<blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:helvetica,arial,sans-serif;font-size:12pt">
<div id="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151m_2027015015759923768m_8813124120249439675m_-7730040808428572051m_-2858323345671407143gmail-m_3630810500302298505DWT50627" dir="ltr"><br>
Example:<br>
<br>
define i1
@bar(i32*
nonnull %x) {
; %x must be
non-null in
this function<br>
%y = load
i32, i32* %x<br>
%z = icmp
ugt i32 %y, 23<br>
ret i1 %z<br>
}<br>
<br>
define i1
@foo(i32* %x)
{<br>
%d = call i1
@bar(i32* %x)<br>
%null_check
= icmp eq i32*
%x, null ;
check if null
after call
that
guarantees
non-null?<br>
br i1
%null_check,
label %t,
label %f<br>
t:<br>
ret i1 1<br>
f:<br>
ret i1 %d<br>
}<br>
<br>
$ opt
-inline
nonnull.ll -S<br>
...<br>
define i1
@foo(i32* %x)
{<br>
%y.i = load
i32, i32* %x
; inlined and
non-null
knowledge is
lost?<br>
</div>
</blockquote>
</span>It
should be
replaced by
!nonnull
metadata on
the load. We
might not be
doing that
today,
however.<span class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151m_2027015015759923768m_8813124120249439675m_-7730040808428572051m_-2858323345671407143gmail-HOEnZb"><font color="#888888">
<div><span></span></div>
</font></span><br>
</div>
</div>
</blockquote>
<div><br>
We can't tag
this load with
!nonnull
though because
this isn't a
load of the
pointer?<br>
"The existence
of the <code class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151m_2027015015759923768m_8813124120249439675m_-7730040808428572051m_-2858323345671407143gmail-docutils m_-201567639833815211m_2993239186205058601gmail-m_8813124120249439675m_-7730040808428572051m_-2858323345671407143gmail-literal"><span class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151m_2027015015759923768m_8813124120249439675m_-7730040808428572051m_-2858323345671407143gmail-pre">!nonnull</span></code>
metadata on
the
instruction
tells the
optimizer that
the value
loaded is
known to never
be null. This
is analogous
to the <code class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151m_2027015015759923768m_8813124120249439675m_-7730040808428572051m_-2858323345671407143gmail-docutils m_-201567639833815211m_2993239186205058601gmail-m_8813124120249439675m_-7730040808428572051m_-2858323345671407143gmail-literal"><span class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151m_2027015015759923768m_8813124120249439675m_-7730040808428572051m_-2858323345671407143gmail-pre">nonnull</span></code>
attribute on
parameters and
return values.
This metadata
can only be
applied to
loads of a
pointer type."
<br>
</div>
</div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
True, but we have
range metadata for
integers.<br>
<br>
-Hal<span><br>
<blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:helvetica,arial,sans-serif;font-size:12pt">
<div dir="ltr">
<div class="gmail_extra"><br>
<br>
</div>
</div>
</blockquote>
<br>
<br>
<br>
-- <br>
<div><span></span>Hal
Finkel<br>
Lead, Compiler
Technology and
Programming
Languages<br>
Leadership
Computing Facility<br>
Argonne National
Laboratory<span></span><br>
</div>
</span></div>
</div>
<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing
list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
<br>
<br>
-- <br>
<div><span name="x"></span>Hal
Finkel<br>
Lead, Compiler Technology and
Programming Languages<br>
Leadership Computing Facility<br>
Argonne National Laboratory<span name="x"></span><br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151m_2027015015759923768mimeAttachmentHeader"></fieldset>
<br>
<pre>______________________________<wbr>_________________
LLVM Developers mailing list
<a class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151m_2027015015759923768moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a class="m_-201567639833815211m_2993239186205058601gmail-m_8203452126618609151m_2027015015759923768moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
</div></div></div>
</blockquote></div>
</div></div>
</blockquote>
</div></div></div></blockquote></div></div></div><br></div></div>
<br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div>