[LLVMdev] [RFC] Stackmap and Patchpoint Intrinsic Proposal

Chandler Carruth chandlerc at google.com
Fri Oct 18 12:07:52 PDT 2013


On Fri, Oct 18, 2013 at 11:08 AM, Andrew Trick <atrick at apple.com> wrote:

> The initial documentation and patches name these intrinsics in a
> "webkit" namespace. This clarifies their current purpose and conveys
> that they haven't been standardized for other JITs yet. If someone on
> the on the dev list says "yes we want to use these too, just the way
> they are", then we can just drop the "webkit" name. More likely, we
> will continue improving their functionality for WebKit until some
> point in the future when another JIT customer tells us they would
> like
> to use the intrinsics but really want to change the interface. At
> that
> point, we can review this again with the goal of standardization and
> backward compatibility, then promote the name. WebKit is maintained
> against LLVM trunk so can be quickly adjusted to a new interface. The
> same may not be true of other JITs.
>
>
> I recommend, this being the case, to replace 'webkit' with 'experimental'.
> Having webkit in the name implies some dependence on webkit, and there is
> none. Plus, this functionality will be used by outside projects as soon as
> it lands in trunk, and I suspect that having webkit in the initial name
> will end up as a naming incongruity that no one will really think is worth
> the effort to change.
>
>
> You’re correct that there is no dependence. I’m fine dropping the webkit
> name, but only if we can go straight to the final name (no need for
> “experimental”).
>
> Again, the only reason to start with the webkit name is that it’s easy to
> change webkit later to use different intrinsics. I was waiting to see how
> much interest there is in using these instrinsics as-is for other clients.
> So far, there seems to be strong interest. If there isn’t much debate
> regarding the intrinsic format then I’ll drop the webkit name.
>

I'm strongly against naming this "webkit" or anything else to do with any
other single consumer of LLVM which is not even an LLVM project. It is
really confusing and implies a whole boat of things that aren't true.

I don't understand why you are pushing for "the final name or the webkit
name". I think the recommendation of "experimental" is great. It clarifies
that the exact interface isn't fully baked and may change, and clients must
be prepared to update following LLVM trunk as opposed to expecting full
backwards compatibility.

If this feature were *only* applicable to WebKit, I'm not even sure it
would belong in the main open source repository. But it isn't, it's a
really interesting general purpose feature for doing dynamic patching of
call sites, and we should figure out a way to design and evolve it as such.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131018/142115cc/attachment.html>


More information about the llvm-dev mailing list