[LLVMdev] Stack maps no longer experimental in 3.5

[Juergen Ributzka]

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>