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 >
Couldn’t we just use the auto upgrader for this? -Juergen On Jun 8, 2014, at 1:09 PM, Eric Christopher <echristo at gmail.com> wrote:> 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 >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140609/ffbe2892/attachment.html>
Only on bitcode that's already written, but I was assuming that Filip had code that used the textual name of the intrinsic as a lookup to get it which autoupgrade I didn't think would fix? (I could be wrong here). -eric On Mon, Jun 9, 2014 at 10:55 AM, Juergen Ributzka <juergen at apple.com> wrote:> Couldn’t we just use the auto upgrader for this? > -Juergen > > On Jun 8, 2014, at 1:09 PM, Eric Christopher <echristo at gmail.com> wrote: > > 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 > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >
On Jun 8, 2014, at 1:09 PM, Eric Christopher <echristo at gmail.com> wrote:> 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.This is clearly good for JITs and doesn’t have to be anything fancy. Anyone want to file a PR for it? -Andy>> -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 >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140611/f9874f1e/attachment.html>