<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 12/01/2014 11:14 AM, Andrew Trick
wrote:<br>
</div>
<blockquote
cite="mid:3C814DCF-2BCF-413A-906F-560B84918529@apple.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Oct 21, 2014, at 4:03 PM, Philip Reames <<a
moz-do-not-send="true"
href="mailto:listmail@philipreames.com" class="">listmail@philipreames.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class=""><span style="font-family: Helvetica; font-size:
12px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height:
normal; orphans: auto; text-align: start; text-indent:
0px; text-transform: none; white-space: normal; widows:
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;
float: none; display: inline !important;" class="">Sanjoy
made a good point. We don't actually need a new variant
of "invariant.start". Simply using an invariant.start
with no uses gives us a notion of an invariant region with
no end. (Since the result doesn't escape, there can be no
end hidden inside a function call.) This seems like a
simple notion to exploit and is strict step forward from
where we are, without a new intrinsic.</span></div>
</blockquote>
</div>
<br class="">
<div class="">
<div class="">I'm coming back to this because it is a sticking
point for me in all of the proposals that were floated
informally on the commits list. I would really like this to
work, but can't prove that it's safe.</div>
</div>
</blockquote>
As I said in the other thread, !invariant.load and llvm.invariant.*
are not the same. This thread is discussing the later, not the
former. The other thread is discussing the former, but not the
later. <br>
<blockquote
cite="mid:3C814DCF-2BCF-413A-906F-560B84918529@apple.com"
type="cite">
<div class="">
<div class=""><br class="">
</div>
<div class="">Given:</div>
<div class=""><br class="">
</div>
<div class="">%a = newArray()</div>
<div class="">%pLen = gep(%a, <length offset>)</div>
<div class="">invariant.start(<size>, %pLen)</div>
<div class="">%len = load %pLen</div>
<div class=""><br class="">
</div>
<div class="">%o = foo() // may deallocate %a</div>
<div class="">store %something</div>
<div class="">load %o</div>
<div class=""><br class="">
</div>
<div class="">I want to claim that the LLVM optimizer cannot do
the following (but don't have a complete line of reasoning
yet):</div>
<div class=""><br class="">
</div>
<div class="">%a = newArray()</div>
<div class="">%pLen = gep(%a, <length offset>)</div>
<div class="">invariant.start(<size>, %pLen)</div>
<div class="">%len = load %pLen</div>
<div class=""><br class="">
</div>
<div class="">%o = foo() // may deallocate %a</div>
<div class="">if ptrtoint(%o) == ptrtoint(%pLen)</div>
<div class=""> load %pLen</div>
<div class=""> store %something // Oops... this might alias</div>
<div class="">else</div>
<div class=""> store %something</div>
<div class=""> load %o</div>
</div>
</blockquote>
Just to make sure we're on the same page, it *would* be legal for
the optimizer to construct:<br>
<div class="">%a = newArray()</div>
<div class="">%pLen = gep(%a, <length offset>)</div>
<div class="">invariant.start(<size>, %pLen)</div>
<div class="">%len = load %pLen</div>
<div class=""><br class="">
</div>
<div class="">%o = foo() // may deallocate %a</div>
<div class="">if ptrtoint(%o) == ptrtoint(%pLen)</div>
<div class=""> store %something // Oops... this might alias<br>
load %pLen <--- This is now after the store<br>
</div>
<div class="">else</div>
<div class=""> store %something</div>
<div class=""> load %o<br>
<br>
Are we in agreement here? <br>
<br>
What is the argument that you see leading from the second to your
problematic example? I'm missing the reasoning by which you got
there. I agree that the example is problematic, I'm just not sure
how it would arise. <br>
</div>
<br>
<br>
<blockquote
cite="mid:3C814DCF-2BCF-413A-906F-560B84918529@apple.com"
type="cite">
<div class="">
<div class=""><br class="">
</div>
<div class="">Either we need to make a convincing argument, or
bail on most of the tentative proposals for expressing
invariance, and resort to generating IR like this:</div>
<div class=""><br class="">
</div>
<div class="">%a = newArray()</div>
<div class="">%pLen = gep(%a, <length offset>)</div>
<div class="">%t = invariant.start(<size>, %pLen)</div>
<div class="">%len = load %pLen</div>
<div class=""><br class="">
</div>
<div class="">%o = foo() // may deallocate %a</div>
<div class="">invariant.end(%t, <size>, %pLen)</div>
<div class="">store %something</div>
<div class="">load %o</div>
<div class=""><br class="">
</div>
<div class="">...which is pretty painful to implement and may be
very difficult to optimize.</div>
</div>
<div class=""><br class="">
</div>
<div class="">-Andy</div>
</blockquote>
<br>
</body>
</html>