llvm dev - Jun 2014 - [LLVMdev] Stack maps no longer experimental in 3.5

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

That would work. :-)

What about exposing C API a function to query for the presence of an intrinsic?

-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

On Sat, Jun 7, 2014 at 9:35 AM, Filip Pizlo <fpizlo at apple.com> wrote:
> That would work. :-)
>
> What about exposing C API a function to query for the presence of an
> intrinsic?
>
I don't know almost anything about how the C API works, but is it possible
to do something like `getHandleToIntrinsic(Module,
"llvm.experimental.patchpoint") == nullptr`? (I doubt that the
function is
actually called "getHandleToIntrinsic", but you get the idea)

-- Sean Silva

>
> -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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140607/4f3ad9ee/attachment.html>

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.

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.

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(!).

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