<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 10/27/2014 08:46 AM, David Blaikie
wrote:<br>
</div>
<blockquote
cite="mid:CAENS6EvScy30XvzpwHsJGnpGh_FRTCMv8U09q6fA5eeJx8U_Hg@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Oct 27, 2014 at 2:59 AM,
David Chisnall <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:David.Chisnall@cl.cam.ac.uk"
target="_blank">David.Chisnall@cl.cam.ac.uk</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">On 27
Oct 2014, at 09:33, Alex Bradbury <<a
moz-do-not-send="true" href="mailto:asb@asbradbury.org"
target="_blank">asb@asbradbury.org</a>> wrote:<br>
<br>
> The Haskell community have put together a [proposal
for an improved LLVM<br>
> backend to GHC](<a moz-do-not-send="true"
href="https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend"
target="_blank">https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend</a>).<br>
> They intend to ship GHC with its own local LLVM
build.<br>
<br>
This post brings up an interesting point:<br>
<br>
> 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.<br>
><br>
> 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.<br>
<br>
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).<br>
</blockquote>
<div><br>
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.<br>
</div>
</div>
</div>
</div>
</blockquote>
+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. <br>
<blockquote
cite="mid:CAENS6EvScy30XvzpwHsJGnpGh_FRTCMv8U09q6fA5eeJx8U_Hg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
(& 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)<br>
<br>
- David</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a class="moz-txt-link-freetext" href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
</pre>
</blockquote>
<br>
</body>
</html>