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

Tue Feb 16 02:45:25 PST 2016

I try to follow ToT closely. The amount of work required keeping things running is similar (some say slightly higher), but it gives you the advantage that the changes themselves are smaller and the set of commits you have to look at to find out what changed and what it was replaced by is much smaller (compensating for the lack of documentation of those changes and their replacements).

--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roemer at igd.fraunhofer.de  |  www.igd.fraunhofer.de

-----Original Message-----
From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Andrew Trick via llvm-dev
Sent: Tuesday, February 16, 2016 11:31
To: David Chisnall
Cc: llvm-dev
Subject: Re: [llvm-dev] WebKit B3 (was LLVM Weekly - #110, Feb 8th 2016)

> 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
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev