llvm dev - Oct 2013 - [LLVMdev] [RFC] Stackmap and Patchpoint Intrinsic Proposal

On Oct 18, 2013, at 11:08 AM, Andrew Trick <atrick at apple.com> wrote:
>> 
>> 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”).
I think that Hal's idea of "experimental" is the right approach
here.  The major thing we want is to avoid having to be backwards compatible
with this intrinsic in subsequent llvm releases.  "experimental" sends
that message, where webkit does not (and is also bad for the reasons Hal
mentions).

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131018/5036fd8f/attachment.html>

On Oct 18, 2013, at 12:39 PM, Chris Lattner <clattner at apple.com> wrote:
> On Oct 18, 2013, at 11:08 AM, Andrew Trick <atrick at apple.com>
wrote:
> 
>>> 
>>> 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”).
> 
> I think that Hal's idea of "experimental" is the right
approach here.  The major thing we want is to avoid having to be backwards
compatible with this intrinsic in subsequent llvm releases. 
"experimental" sends that message, where webkit does not (and is also
bad for the reasons Hal mentions).
Done. I’ll update the patches on llvm-commits.

For the record, I wasn’t aware of any precedent for “llvm.experimental”, but if
it will help avoid backward compatibility issues then it’s a good thing.

-Andy

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131018/009e7080/attachment.html>

On Fri, Oct 18, 2013 at 1:37 PM, Andrew Trick <atrick at apple.com> wrote:
> For the record, I wasn’t aware of any precedent for “llvm.experimental”,
> but if it will help avoid backward compatibility issues then it’s a good
> thing.
>
I don't think we have precedent, but I think it will be really good to
establish precedent. =]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131018/d796a39d/attachment.html>

On Oct 18, 2013, at 12:39 PM, Chris Lattner <clattner at apple.com> wrote:
> On Oct 18, 2013, at 11:08 AM, Andrew Trick <atrick at apple.com>
wrote:
> 
>>> 
>>> 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”).
> 
> I think that Hal's idea of "experimental" is the right
approach here.  The major thing we want is to avoid having to be backwards
compatible with this intrinsic in subsequent llvm releases. 
"experimental" sends that message, where webkit does not (and is also
bad for the reasons Hal mentions).
What would be the criteria for eventually dropping 'experimental' from
the intrinsic names?

Evan
> 
> -Chris
> 
> _______________________________________________
> 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/20131018/36c2e842/attachment.html>

On Oct 18, 2013, at 2:59 PM, Evan Cheng <evan.cheng at apple.com> wrote:
> 
> On Oct 18, 2013, at 12:39 PM, Chris Lattner <clattner at apple.com>
wrote:
> 
>> On Oct 18, 2013, at 11:08 AM, Andrew Trick <atrick at apple.com>
wrote:
>> 
>>>> 
>>>> 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”).
>> 
>> I think that Hal's idea of "experimental" is the right
approach here.  The major thing we want is to avoid having to be backwards
compatible with this intrinsic in subsequent llvm releases. 
"experimental" sends that message, where webkit does not (and is also
bad for the reasons Hal mentions).
> 
> What would be the criteria for eventually dropping 'experimental'
from the intrinsic names?
At the least, I'd like to get some experience on these.  Having webkit
actually ship something based on this seems like a minimal requirement to
demonstrate that it will actually work (end to end) in practice.  Beyond that,
we'd want to be happy enough with it that we'd be willing to autoupgrade
it if it ever evolves in future releases: i.e. we'd be promising backward
compatibility with the intrinsic.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131018/12f8e9df/attachment.html>