LLVM Weekly - #43, Oct 27th 2014

LLVM Weekly - #43, Oct 27th 2014

The Haskell community have put together a [proposal for an improved LLVM
backend to GHC](https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend).
They intend to ship GHC with its own local LLVM build.

This post brings up an interesting point:

However, the framework is modular - we can extend LLVM with plugins. For example, several years ago, Max Bolingbroke ​wrote a plugin for LLVM's alias analysis that improved the generated code in some cases by 12%, just by teaching it GHC-specific code generation needs.

However, due to lack of API guarantees mentioned above, it becomes difficult to support such analysis for arbitrary end users, and we cannot fix or tune analysis results to specific versions of LLVM or GHC.

This is a problem for anyone with an out-of-tree LLVM front end, or library, that would benefit from some custom optimisations. Without even a nod towards API (let alone ABI) stability for the core IR classes, it's very hard for people to gain the full benefit of using LLVM, unless their code is part of the LLVM tree and follows the same release cycle as LLVM (which doesn't scale).

David

I don't know that many of the major contributors follow the LLVM release
cycle, fwiw - one of the reasons we all care about stability on ToT so very
much.

(& at least Apple likely has lots of fun internal toys and they manage to
follow ToT pretty closely, not sure about other major contributors - kind
of the nature of many groups who keep their work out of ToT is that they're
not involved in the community)

- David

+1 on this. I use Clang on the release schedule, but our LLVM work tracks TOT. IMHO, trying to do anything else for an embedded compiler in a VM is pure folly and will lead to worlds of pain.

Nick Lewycky is currently doing Google's internal Clang releases, and we
actually tag them in svn over here:
http://llvm.org/viewvc/llvm-project/llvm/tags/google/stable/
http://llvm.org/viewvc/llvm-project/cfe/tags/google/stable/

I would only recommend using this release cadence for Clang if you have the
resources to stay up to date on fallout from warnings, C++ defect reports,
and such. I expect most users aren't willing to deal with that.

Reid Kleckner wrote:

    +1 on this. I use Clang on the release schedule, but our LLVM work
    tracks TOT. IMHO, trying to do anything else for an embedded
    compiler in a VM is pure folly and will lead to worlds of pain.

Nick Lewycky is currently doing Google's internal Clang releases, and we
actually tag them in svn over here:
http://llvm.org/viewvc/llvm-project/llvm/tags/google/stable/
http://llvm.org/viewvc/llvm-project/cfe/tags/google/stable/

I would only recommend using this release cadence for Clang if you have
the resources to stay up to date on fallout from warnings, C++ defect
reports, and such. I expect most users aren't willing to deal with that.

Basing your internal releases off of our stable tags is probably a good idea. We test aggressively, and since we try to update weekly, you can simply pick our latest tag whenever you're ready.

However, we recently started cherrypicking additional revisions on top of the ones we mark stable, and those aren't reflected upstream. If you have any ideas on how we should handle that, please let me know. It's on our todo list to do something about it, but I haven't figured out what that "something" should be yet. Note that we currently tag, not branch, and we probably don't want to branch all of llvm+clang+compiler_rt every week.

Nick

Why not branch instead of tag? Subversion makes this no more expensive. Then we could track cherrypicks in it correctly.