<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: arial,helvetica,sans-serif; font-size: 10pt; color: #000000'><br><hr id="zwchr"><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>"Hal Finkel" <hfinkel@anl.gov><br><b>To: </b>"Hal Finkel" <hfinkel@anl.gov><br><b>Cc: </b>"llvm-dev" <llvm-dev@lists.llvm.org>, "Geoff Berry" <gberry@codeaurora.org><br><b>Sent: </b>Thursday, August 25, 2016 3:12:08 PM<br><b>Subject: </b>Re: [llvm-dev] invariant.load metadata semantics<br><br>
<style>p { margin: 0; }</style><div id="DWT9812" style="font-family: arial,helvetica,sans-serif; font-size: 10pt; color: rgb(0, 0, 0);"><br><hr id="zwchr"><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>"Hal Finkel via llvm-dev" <llvm-dev@lists.llvm.org><br><b>To: </b>"Geoff Berry" <gberry@codeaurora.org><br><b>Cc: </b>"llvm-dev" <llvm-dev@lists.llvm.org><br><b>Sent: </b>Thursday, August 25, 2016 3:05:48 PM<br><b>Subject: </b>Re: [llvm-dev] invariant.load metadata semantics<br><br>
<style>p { margin: 0; }</style><div id="DWT9652" style="font-family: arial,helvetica,sans-serif; font-size: 10pt; color: rgb(0, 0, 0);"><br><hr id="zwchr"><blockquote id="DWT9447" 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>"Geoff Berry via llvm-dev" <llvm-dev@lists.llvm.org><br><b>To: </b>"llvm-dev" <llvm-dev@lists.llvm.org><br><b>Sent: </b>Thursday, August 25, 2016 2:23:01 PM<br><b>Subject: </b>[llvm-dev] invariant.load metadata semantics<br><br>
<p>I'm working on enhancing EarlyCSE to use MemorySSA and have come
across the following issue due to differences in EarlyCSE and
MemorySSA's handling of !invariant.load. EarlyCSE will *not*
currently optimize the following code by replacing %x2 with %x and
removing the second load:<br>
</p>
<blockquote>
<p>B1:<br>
</p>
<p> %x = load %p</p>
<p> clobber()<br>
</p>
...<br>
<br>
B2: // dominated by B1<br>
<br>
%x2 = load %p !invariant.load<br>
</blockquote>
<br>
Sanjoy (who added the !invariant.load support to EarlyCSE) and I
discussed this, and I believe we are both in agreement that this
optimization should be legal. I'd like to make sure there is
agreement on this and possibly clarify the LangRef wording on
!invariant.load to make the legality of this transformation more
clear.<br>
<br>
Sanjoy suggested the following:<br>
<blockquote id="DWT9446">Instead of "The existence
of the !invariant.load metadata on the instruction tells the
optimizer
and code generator that the address operand to this load points to
memory which can be assumed unchanged." we say "It is undefined
behavior to invariant_load from a location that has been changed
since
it became dereferenceable". In the current langref, I find "The
existence" somewhat confusing, since it seems to imply that adding
dead code can change the behavior of the program.<br>
<br>
I don't want to specify the semantics in a way that:<br>
<br>
int* ptr = ...<br>
int k0 = *ptr; // normal load<br>
clobber();<br>
int k1 = *ptr; // normal load<br>
<br>
has a different meaning than<br>
<br>
int* ptr = ...<br>
int k0 = *ptr; // normal load<br>
clobber();<br>
int k1 = *ptr; // normal load<br>
if (<always false>) {<br>
int k2 = *ptr; // !invariant load<br>
}<br>
<br>
That is, adding dead code should not change the behavior of the<br>
program -- the code guarded by (<always false>) should be
able to have<br>
any amount of junk without breaking the program, since it does not<br>
actually execute.<br></blockquote></blockquote>I agree.<br><br>Regarding the proposed text, I find the "since it became dereferenceable" phrase ambiguous. Further, I think we can say something stronger: Storing into a location previously loaded using a load tagged with !invariant.load is undefined behavior.<br></div></blockquote>Alternatively, we might phrase this as: The optimizer may assume that all values loaded from a location, where any of the loads are tagged with !invariant.load, are identical.<br><br>This has the benefit of covering the fact that no outside entity (i.e. the operating system) changes the value, and that we can change it, but only to the same value it had before (if we'll later be able to observe the difference).<br></div></blockquote>Some questions: Do we allow stores to these locations at all? Only if the value is the same? Must any change be observable to be a problem? Do atomic loads of invariant locations really need to be atomic?<br><br> -Hal<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 style="font-family: arial,helvetica,sans-serif; font-size: 10pt; color: rgb(0, 0, 0);"><br> -Hal<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 style="font-family: arial,helvetica,sans-serif; font-size: 10pt; color: rgb(0, 0, 0);"><br> -Hal<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;"><blockquote>
</blockquote>
<br>
Does this seem like a clearer wording of the intended semantics?<br>
<pre class="moz-signature">-- <br>Geoff Berry<br>Employee of Qualcomm Datacenter Technologies, Inc.<br> Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.</pre>
<br>_______________________________________________<br>LLVM Developers mailing list<br>llvm-dev@lists.llvm.org<br>http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br></blockquote><br><br><br>-- <br><div><span></span>Hal Finkel<br>Assistant Computational Scientist<br>Leadership Computing Facility<br>Argonne National Laboratory<span></span><br></div></div><br>_______________________________________________<br>LLVM Developers mailing list<br>llvm-dev@lists.llvm.org<br>http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br></blockquote><br><br><br>-- <br><div><span></span>Hal Finkel<br>Assistant Computational Scientist<br>Leadership Computing Facility<br>Argonne National Laboratory<span></span><br></div></div></blockquote><br><br><br>-- <br><div><span name="x"></span>Hal Finkel<br>Assistant Computational Scientist<br>Leadership Computing Facility<br>Argonne National Laboratory<span name="x"></span><br></div></div></body></html>