David Blaikie
2014-Oct-27 15:46 UTC
[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>
Philip Reames
2014-Oct-27 16:41 UTC
[LLVMdev] Out-of-tree passes (Was: LLVM Weekly - #43, Oct 27th 2014)
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>
Reid Kleckner
2014-Oct-27 16:55 UTC
[LLVMdev] Out-of-tree passes (Was: LLVM Weekly - #43, Oct 27th 2014)
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>