llvm dev - Oct 2014 - [LLVMdev] Out-of-tree passes (Was: LLVM Weekly - #43, Oct 27th 2014)

On Mon, Oct 27, 2014 at 2:59 AM, David Chisnall <David.Chisnall at
cl.cam.ac.uk
> wrote:
> On 27 Oct 2014, at 09:33, Alex Bradbury <asb at asbradbury.org>
wrote:
>
> > 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).
>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141027/3593e628/attachment.html>

On 10/27/2014 08:46 AM, David Blaikie wrote:
>
>
> On Mon, Oct 27, 2014 at 2:59 AM, David Chisnall 
> <David.Chisnall at cl.cam.ac.uk <mailto:David.Chisnall at
cl.cam.ac.uk>> wrote:
>
>     On 27 Oct 2014, at 09:33, Alex Bradbury <asb at asbradbury.org
>     <mailto:asb at asbradbury.org>> wrote:
>
>     > 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).
>
>
> 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.
+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.
>
> (& 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
>
>
> _______________________________________________
> 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/20141027/42ce46a6/attachment.html>

On Mon, Oct 27, 2014 at 9:41 AM, Philip Reames <listmail at
philipreames.com>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141027/08a7d931/attachment.html>