<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Oct 18, 2013, at 9:37 AM, Sean Silva <<a href="mailto:chisophugis@gmail.com">chisophugis@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br class="Apple-interchange-newline"><br 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;"><br 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;"><div class="gmail_quote" 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;">On Fri, Oct 18, 2013 at 1:39 AM, Andrew Trick<span class="Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:atrick@apple.com" target="_blank">atrick@apple.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><br>The initial documentation and patches name these intrinsics in a<br>"webkit" namespace. This clarifies their current purpose and conveys<br>that they haven't been standardized for other JITs yet. If someone on<br>the on the dev list says "yes we want to use these too, just the way<br>they are", then we can just drop the "webkit" name. More likely, we<br>will continue improving their functionality for WebKit until some<br>point in the future when another JIT customer tells us they would like<br>to use the intrinsics but really want to change the interface. At that<br>point, we can review this again with the goal of standardization and<br>backward compatibility, then promote the name. WebKit is maintained<br>against LLVM trunk so can be quickly adjusted to a new interface. The<br>same may not be true of other JITs.<br></blockquote><div><br></div><div>This sort of functionality could probably be used to greatly improve the usability of DTrace's USDT tracing. </div><div> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><br>These are the proposed changes to LangRef, written by Juergen and me.<br><br>WebKit Intrinsics<br>-----------------<br><br>This class of intrinsics is used by the WebKit JavaScript compiler to obtain<br>additional information about the live state of certain variables and/or to<br>enable the runtime system / JIT to patch the code afterwards.<br><br>The use of the following intrinsics always generates a stack map. The purpose<br>of a stack map is to record the location of function arguments and live<br>variables at the point of the intrinsic function in the instruction steam.<br>Furthermore it records a unique callsite id and the offset from the beginning<br>of the enclosing function.<br><br>'``llvm.webkit.stackmap``' Intrinsic<br>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br><br>Syntax:<br>"""""""<br><br>::<br><br> <span class="Apple-converted-space"> </span>declare void (i32, i32, ...)* @llvm.webkit.stackmap(i32 <id>, i32 <numShadowBytes>, ...)<br><br>Overview:<br>"""""""""<br><br>The '``llvm.webkit.stackmap``' intrinsic records the location of live variables in the stack map without generating any code.<br></blockquote><div><br></div><div>Last I checked LLVM IR doesn't have "variables" in this sense (except globals; it seems like a handful of other places in the LangRef have this wording slip too). Shouldn't the wording be more like "the run time location of the provided values"?</div><div> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><br>Arguments:<br>""""""""""<br><br>The first argument is a unique id and the second argument is the number of<br>shadow bytes following the intrinsic. The variable number of arguments after<br>that are the live variables.<br></blockquote><div><br></div><div>The purpose of the "id" isn't described.</div><div> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><br>Semantics:<br>""""""""""<br><br>The stackmap intrinsic generates no code in place, but its offset from function<br>entry is stored in the stack map. Furthermore, it guarantees a shadow of<br>instructions following its instruction offset during which neither the end of<br>the function nor another stackmap or patchpoint intrinsic may occur.</blockquote><div> </div><div>It's meaningless to discuss the semantics when important terms are undefined:</div><div>* "stack map" (and the format of a stack map, and where it is emitted/how it can be accessed, etc.)</div><div>* "shadow": while it's fairly clear roughly what is meant by this, this is Lang*Ref*, not "LangOverview" or "LangTour"</div><div><br></div><div>It may be that the inherently experimental nature of these intrinsics do not lend itself to being documented adequately enough for inclusion in LangRef at this point, in which case I would suggest demoting this description to a new page for experimental intrinsics until they have settled enough.</div><div><br></div><div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto;"><br class="">This allows the runtime to patch the code at this point in response to an event triggered from outside the code.<br></blockquote></div><div><br></div><div>Here and elsewhere, I suggest avoiding saying "the runtime". It is more accurate to describe properties of the code, rather than the runtime (which LLVM doesn't provide and which is not a concept in the LangRef). For example this sentence could be "This permits the code to be safely patched”.</div></div></blockquote><div><br></div></div>100% agree with all your comments. I’m pulling the intrinsic docs into a separate page. I’ll create a phabricator diff and we can continue reviewing the docs on llvm-commits independent of this proposal.<div><br></div><div>-Andy</div></body></html>