<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 21, 2014, at 4:03 PM, Philip Reames <<a 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 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 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></body></html>