[LLVMdev] Stack maps no longer experimental in 3.5

[Juergen Ributzka]

Dang. Yes, you are right. I forgot that we only run the autoupgrader on files that we read in and not on IR that is generated with C API calls.
-Juergen

On Jun 10, 2014, at 2:30 PM, Eric Christopher <echristo at gmail.com> wrote:

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