[LLVMdev] Stack maps no longer experimental in 3.5

[Eric Christopher]

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
>
>