[LLVMdev] Out-of-tree passes (Was: LLVM Weekly (original) (raw)

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

Philip Reames listmail at philipreames.com
Mon Oct 27 09:41:25 PDT 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. > 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>



More information about the llvm-dev mailing list