[pypy-commit] pypy default: hg backout 04acdc4163f4: revert the change to the docs that killed most

[arigo]

Author: Armin Rigo <arigo at tunes.org>
Branch: 
Changeset: r70399:21d1db01f2d3
Date: 2014-04-02 19:04 +0200
http://bitbucket.org/pypy/pypy/changeset/21d1db01f2d3/

Log:	hg backout 04acdc4163f4: revert the change to the docs that killed
	most of the reasoning for why we *still* think LLVM is unlikely to
	be a good idea.

diff --git a/pypy/doc/faq.rst b/pypy/doc/faq.rst
--- a/pypy/doc/faq.rst
+++ b/pypy/doc/faq.rst
@@ -429,12 +429,25 @@
 Could we use LLVM?
 ------------------
 
-There is a (static) translation backend using LLVM in the branch
-``llvm-translation-backend``.  It can translate PyPy with or without the JIT on
-Linux.
+In theory yes.  But we tried to use it 5 or 6 times already, as a
+translation backend or as a JIT backend --- and failed each time.
 
-Using LLVM as our JIT backend looks interesting as well -- we made an attempt,
-but it failed: LLVM has no way to patch the generated machine code.
+In more details: using LLVM as a (static) translation backend is
+pointless nowadays because you can generate C code and compile it with
+clang.  (Note that compiling PyPy with clang gives a result that is not
+faster than compiling it with gcc.)  We might in theory get extra
+benefits from LLVM's GC integration, but this requires more work on the
+LLVM side before it would be remotely useful.  Anyway, it could be
+interfaced via a custom primitive in the C code.
+
+On the other hand, using LLVM as our JIT backend looks interesting as
+well --- but again we made an attempt, and it failed: LLVM has no way to
+patch the generated machine code.
+
+So the position of the core PyPy developers is that if anyone wants to
+make an N+1'th attempt with LLVM, they are welcome, and will be happy to
+provide help in the IRC channel, but they are left with the burden of proof
+that (a) it works and (b) it gives important benefits.
 
 ----------------------
 How do I compile PyPy?