<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div> <br><p style="color:#000;">On June 7, 2014 at 1:29:04 PM, Alp Toker (<a href="mailto:alp@nuanti.com">alp@nuanti.com</a>) wrote:</p> <div><div><div><blockquote type="cite" class="clean_bq" style="color: rgb(0, 0, 0); font-family: Helvetica, Arial; font-size: 13px; 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; background-color: rgb(255, 255, 255);"><span><div><div></div><div><br>On 07/06/2014 18:35, Filip Pizlo wrote:<span class="Apple-converted-space"> </span><br>> That would work. :-)<span class="Apple-converted-space"> </span><br>><span class="Apple-converted-space"> </span><br>> What about exposing C API a function to query for the presence of an intrinsic?<span class="Apple-converted-space"> </span><br><br>It seems with hindsight that the "experimental" prefix has turned out to<span class="Apple-converted-space"> </span><br>be a waste of time.<span class="Apple-converted-space"> </span></div></div></span></blockquote></div><p>It's only a waste of time if you think that run-time feature detection is a bad idea. I believe that run-time feature detection is a good idea even if we didn't need it in this particular case.</p><div><blockquote type="cite" class="clean_bq" style="color: rgb(0, 0, 0); font-family: Helvetica, Arial; font-size: 13px; 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; background-color: rgb(255, 255, 255);"><span><div><div><br><br>At least without the prefix there was a good chance this churn could be<span class="Apple-converted-space"> </span><br>avoided as long as the original review was sound, whereas the prefix has<span class="Apple-converted-space"> </span><br>necessitated churn.<span class="Apple-converted-space"> </span></div></div></span></blockquote></div></div><p>The intrinsic changed a fair bit since the original review. Both its signature and the stackmap format changed.</p><div><blockquote type="cite" class="clean_bq" style="color: rgb(0, 0, 0); font-family: Helvetica, Arial; font-size: 13px; 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; background-color: rgb(255, 255, 255);"><span><div><div><br><br>I suggest performing a configure-time check in your build system to<span class="Apple-converted-space"> </span><br>retain backward/forward compatibility instead of attempting to specify C<span class="Apple-converted-space"> </span><br>API for instruction introspection(!).<span class="Apple-converted-space"> </span></div></div></span></blockquote></div></div><p>Run-time checks are more robust than configure-time checks. LLVM is a moving target and new intrinsics are added all the time, and it shouldn't be necessary to recompile all users of LLVM just to get them to recognize that the LLVM to which they got linked has the intrinsic that they already knew about.</p><p>-Filip</p><p><br></p><div><blockquote type="cite" class="clean_bq" style="color: rgb(0, 0, 0); font-family: Helvetica, Arial; font-size: 13px; 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; background-color: rgb(255, 255, 255);"><span><div><div><br><br>Alp.<span class="Apple-converted-space"> </span><br><br>><span class="Apple-converted-space"> </span><br>> -Fil<span class="Apple-converted-space"> </span><br>><span class="Apple-converted-space"> </span><br>>> On Jun 7, 2014, at 3:37 AM, Rafael Espíndola <rafael.espindola@gmail.com> wrote:<span class="Apple-converted-space"> </span><br>>><span class="Apple-converted-space"> </span><br>>>> On 7 June 2014 00:14, Filip Pizlo <fpizlo@apple.com> wrote:<span class="Apple-converted-space"> </span><br>>>> The only setback is to ensure that we synchronize the renaming with WebKit.<span class="Apple-converted-space"> </span><br>>>><span class="Apple-converted-space"> </span><br>>>> The WebKit->LLVM interface currently avoids revision-lock; you can take any<span class="Apple-converted-space"> </span><br>>>> recent revision of either and build a working browser engine. This is mostly<span class="Apple-converted-space"> </span><br>>>> true even when we change the stack map format because of versioning in the<span class="Apple-converted-space"> </span><br>>>> format. I'd rather keep it that way.<span class="Apple-converted-space"> </span><br>>>><span class="Apple-converted-space"> </span><br>>>> Is there a way to do this with intrinsics? I.e. is there a safe way for<span class="Apple-converted-space"> </span><br>>>> WebKit to query whether "llvm.patchpoint" is an available intrinsic, and<span class="Apple-converted-space"> </span><br>>>> then fallback to "llvm.experimental.patchpoint" if it's not available?<span class="Apple-converted-space"> </span><br>>> Keeping both names during a smallish time window should be sufficient, no?<span class="Apple-converted-space"> </span><br>>><span class="Apple-converted-space"> </span><br>>> Cheers,<span class="Apple-converted-space"> </span><br>>> Rafael<span class="Apple-converted-space"> </span><br>> _______________________________________________<span class="Apple-converted-space"> </span><br>> LLVM Developers mailing list<span class="Apple-converted-space"> </span><br>> LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu<span class="Apple-converted-space"> </span><br>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev<span class="Apple-converted-space"> </span><br><br>--<span class="Apple-converted-space"> </span><br>http://www.nuanti.com<span class="Apple-converted-space"> </span><br>the browser experts<span class="Apple-converted-space"> </span><br><br></div></div></span></blockquote></div></body></html>