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