[LLVMdev] Stack maps no longer experimental in 3.5
Andrew Trick
atrick at apple.com
Wed Jun 11 16:08:04 PDT 2014
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>
More information about the llvm-dev
mailing list