llvm dev - Feb 2016 - 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

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

On Tue, 16 Feb 2016 10:45:25 +0000
"Mueller-Roemer, Johannes Sebastian via llvm-dev"
<llvm-dev at lists.llvm.org> wrote:
> 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).
For llvmlite, we typically wait for a X.Y.1 release.  Switching from
X.Y-1.1 to X.Y.1 takes a few days on average.  We ship binaries for
several platforms (Linux, OS X, Windows) and using SVN head would have
us suffer from whatever temporary instabilities or regressions have
been introduced.

Regards

Antoine.