[llvm-dev] WebKit B3 (was LLVM Weekly - #110, Feb 8th 2016)

[Andrew Trick via llvm-dev]

> On Feb 16, 2016, at 1:14 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:
> 
> On 15 Feb 2016, at 23:12, Andrew Trick via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> 
>> Prior to FTL, JavaScriptCore had no dependence on the LLVM project. Maintaining a dependence on an external project naturally has integration overhead.
> 
> And the fact that a company that has as much in-house LLVM expertise as Apple decided that this was a significant burden is something that we should take note of.  LLVM is particularly unfriendly to out-of-tree developers, with no attempt made to provide API compatibility between releases.  I maintain several out-of-tree projects that use LLVM and the effort involved in moving between major releases is significant (and not much more than the effort involved in moving between svn head revisions so, like most other projects, I don’t test with head until there’s a release candidate - or often after the release, if I don’t have a few days to update to the new APIs, which means that we lose out on a load of testing that other library projects get for free).  Methods are removed or renamed with no deprecation warnings and often without any documentation indicating what their usage should be replaced with.  Even for a fairly small project, upgrading between point releases of LLVM is typically a few days of effort.


Thanks David,

The integration burden is something to raise awareness of. I thought failing to mention it would be disingenuous. It needs to factor into anyone's plans to integrate LLVM into their runtime. I'll reiterate that I do not speak for the WebKit team or their motivation. I don't think integration burden is any less whether you work for one company or another, or have "in-house" expertise, and I know that API breakage can't be blamed on a particular company.

Bottom line (to risk stating the obvious):

- runtime compiler integration is even harder than static compiler integration

- don't expect to piggyback on LLVM's continual advances without continually engaging the LLVM open source community

I think either of these topics, MCJIT design and general API migration, would be great to discuss in separate threads.

Andy