On 07/06/2014 18:35, Filip Pizlo wrote:> That would work. :-) > > What about exposing C API a function to query for the presence of an intrinsic?It seems with hindsight that the "experimental" prefix has turned out to be a waste of time. At least without the prefix there was a good chance this churn could be avoided as long as the original review was sound, whereas the prefix has necessitated churn. I suggest performing a configure-time check in your build system to retain backward/forward compatibility instead of attempting to specify C API for instruction introspection(!). Alp.> > -Fil > >> On Jun 7, 2014, at 3:37 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> >>> On 7 June 2014 00:14, Filip Pizlo <fpizlo at apple.com> wrote: >>> The only setback is to ensure that we synchronize the renaming with WebKit. >>> >>> The WebKit->LLVM interface currently avoids revision-lock; you can take any >>> recent revision of either and build a working browser engine. This is mostly >>> true even when we change the stack map format because of versioning in the >>> format. I'd rather keep it that way. >>> >>> Is there a way to do this with intrinsics? I.e. is there a safe way for >>> WebKit to query whether "llvm.patchpoint" is an available intrinsic, and >>> then fallback to "llvm.experimental.patchpoint" if it's not available? >> Keeping both names during a smallish time window should be sufficient, no? >> >> Cheers, >> Rafael > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-- http://www.nuanti.com the browser experts
On June 7, 2014 at 1:29:04 PM, Alp Toker (alp at nuanti.com) wrote: On 07/06/2014 18:35, Filip Pizlo wrote:> That would work. :-) > > What about exposing C API a function to query for the presence of an intrinsic?It seems with hindsight that the "experimental" prefix has turned out to be a waste of time. 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. At least without the prefix there was a good chance this churn could be avoided as long as the original review was sound, whereas the prefix has necessitated churn. The intrinsic changed a fair bit since the original review. Both its signature and the stackmap format changed. I suggest performing a configure-time check in your build system to retain backward/forward compatibility instead of attempting to specify C API for instruction introspection(!). 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. -Filip Alp.> > -Fil > >> On Jun 7, 2014, at 3:37 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> >>> On 7 June 2014 00:14, Filip Pizlo <fpizlo at apple.com> wrote: >>> The only setback is to ensure that we synchronize the renaming with WebKit. >>> >>> The WebKit->LLVM interface currently avoids revision-lock; you can take any >>> recent revision of either and build a working browser engine. This is mostly >>> true even when we change the stack map format because of versioning in the >>> format. I'd rather keep it that way. >>> >>> Is there a way to do this with intrinsics? I.e. is there a safe way for >>> WebKit to query whether "llvm.patchpoint" is an available intrinsic, and >>> then fallback to "llvm.experimental.patchpoint" if it's not available? >> Keeping both names during a smallish time window should be sufficient, no? >> >> Cheers, >> Rafael > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-- http://www.nuanti.com the browser experts -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140607/185e8edd/attachment.html>
On Sat, Jun 7, 2014 at 6:30 PM, Filip Pizlo <fpizlo at apple.com> wrote:> > > On June 7, 2014 at 1:29:04 PM, Alp Toker (alp at nuanti.com) wrote: > > > On 07/06/2014 18:35, Filip Pizlo wrote: >> That would work. :-) >> >> What about exposing C API a function to query for the presence of an >> intrinsic? > > It seems with hindsight that the "experimental" prefix has turned out to > be a waste of time. > > 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. > > > > At least without the prefix there was a good chance this churn could be > avoided as long as the original review was sound, whereas the prefix has > necessitated churn. > > The intrinsic changed a fair bit since the original review. Both its > signature and the stackmap format changed. > > > > I suggest performing a configure-time check in your build system to > retain backward/forward compatibility instead of attempting to specify C > API for instruction introspection(!). > > 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. >Agreed. Sean's idea might work? If not, then I'm down for coming up with something. -eric> -Filip > > > > > Alp. > >> >> -Fil >> >>> On Jun 7, 2014, at 3:37 AM, Rafael Espíndola <rafael.espindola at gmail.com> >>> wrote: >>> >>>> On 7 June 2014 00:14, Filip Pizlo <fpizlo at apple.com> wrote: >>>> The only setback is to ensure that we synchronize the renaming with >>>> WebKit. >>>> >>>> The WebKit->LLVM interface currently avoids revision-lock; you can take >>>> any >>>> recent revision of either and build a working browser engine. This is >>>> mostly >>>> true even when we change the stack map format because of versioning in >>>> the >>>> format. I'd rather keep it that way. >>>> >>>> Is there a way to do this with intrinsics? I.e. is there a safe way for >>>> WebKit to query whether "llvm.patchpoint" is an available intrinsic, and >>>> then fallback to "llvm.experimental.patchpoint" if it's not available? >>> Keeping both names during a smallish time window should be sufficient, >>> no? >>> >>> Cheers, >>> Rafael >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > -- > http://www.nuanti.com > the browser experts > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >