[pypy-svn] r14766 - pypy/dist/pypy/documentation

cfbolz at codespeak.net cfbolz at codespeak.net
Tue Jul 19 14:25:54 CEST 2005


Author: cfbolz
Date: Tue Jul 19 14:25:53 2005
New Revision: 14766

Modified:
   pypy/dist/pypy/documentation/translation.txt
Log:
removed documentation about llvm1


Modified: pypy/dist/pypy/documentation/translation.txt
==============================================================================
--- pypy/dist/pypy/documentation/translation.txt	(original)
+++ pypy/dist/pypy/documentation/translation.txt	Tue Jul 19 14:25:53 2005
@@ -864,130 +864,9 @@
 The LLVM Back-End
 =================
 
-http://codespeak.net/svn/pypy/dist/pypy/translator/llvm/
+http://codespeak.net/svn/pypy/dist/pypy/translator/llvm2/
 
-
-Overview
---------
-
-Note that the LLVM back-end is in a state of constant flux and thus this are
-preliminary notes only.
-
-The task of GenLLVM is to convert a flow graph into `LLVM code`_, which can
-then be optimized and compiled by LLVM. GenLLVM depends heavily on the
-annotations, functions without annotations cannot be translated. The flowgraph
-is not changed by GenLLVM in contrast to GenC. After the generation and
-compilation of the LLVM code a wrapper is generated (at the moment with the
-help of Pyrex) wich performs the conversion of arguments and return value of
-the entry function to the types used by LLVM. Thus it is possible to call the
-entry function from Python.
-
-GenLLVM does not depend on the CPython runtime which has the drawback that most
-functions with SomeObject annotations cannot be compiled properly -- the only
-operations that are allowed on variables with SomeObject annotations are
-``isinstance`` and ``type``.
-
-GenLLVM creates for every object in the flow graph (e.g. constants, variables,
-blocks...) an LLVM 'representation'. This representation knows how to
-represent the corresponding object in LLVM and knows what code to generate for
-space operations on the object, what global definitions the object needs etc.
-
-Some examples to make this clearer: A `ClassRepr`_ object represents a class, a
-`FuncRepr`_ object represent a function (or method). The following happens if
-the space operation ``simple_call`` is performed on a function: An appropriate
-``FuncRepr`` object is constructed which generates LLVM code for the function
-it represents. Then the ``FuncRepr`` inserts the appropriate LLVM instructions
-into the LLVM code of the function it is called from (sometime this is more
-than just a call: the arguments have to be casted, etc). Something similar
-happens if a class is instantiated: A ``ClassRepr`` is created which then
-generates LLVM code that allocates enough memory for an instance of the class
-and then (if the class or a base class has an ``__init__`` method) tells the
-``FuncRepr`` of the appropriate ``__init__`` method to generate the code for
-the call to it.
-
-Every representation object has some other representations it depends on: A
-``ListRepr`` of lists instances of a class depends on the ``ClassRepr`` of
-that class. To ensure that the typedef of the class is written to the llvm
-file before the typedef of the list, the dependency tree of representations
-traversed depth first when the LLVM code is written to a file.
-
-.. _`LLVM code`: http://www.llvm.org
-.. _`ClassRepr`: http://codespeak.net/svn/pypy/dist/pypy/translator/llvm/classrepr.py
-.. _`FuncRepr`: http://codespeak.net/svn/pypy/dist/pypy/translator/llvm/funcrepr.py
-
-
-Details about the representations
----------------------------------
-
-Simple representations
-++++++++++++++++++++++
-
-There are some objects that have direct counterparts in LLVM: ints, floats,
-chars (strings of length 1), bools. Most space operations involving those are
-implemented as `tiny function`_ (LLVM doesn't support macros since LLVM's .ll
-files correspond directly to its bytecode format so that round trip
-conversions are nearly lossless). These are so simple that they are always
-inlined by the LLVM optimizer so this doesn't lead to any performance penalty.
-
-
-Function representation
-+++++++++++++++++++++++
-
-The representation of function in LLVM code is relatively easy since LLVM as
-well as flow graph use SSA form. Furthermore LLVM supports exactly the kind of
-control structures that the flow graphs feature: A function consists of basic
-blocks that end with links to other blocks, data flows along these links. The
-data flow is handled in LLVM by phi nodes: at the beginning of every block phi
-nodes may be inserted. Those determine the value of a variable depending on
-which block branched to the currect block. Example::
-
-    block1:
-        %b = phi int [1, %block0], [2, %block2]
-
-Here %b is 1 if control came from block0 and 2 if control came from block2.
-
-The following code is generated for the function ``g`` defined above_::
-
-    int %g(int %n1) {
-    block0:
-        br label %block1
-    block1:
-        %n2 = phi int [%n1, %block0], [%m3, %block3]
-        %i2 = phi int [0, %block0], [%j3, %block3]
-        %v2 = call bool %std.is_true(int %n2)
-        br bool %v2, label %block3, label %block2
-    block2:
-        %i4 = phi int [%i2, %block1]
-        ret int %i4
-    block3:
-        %n3 = phi int [%n2, %block1]
-        %i3 = phi int [%i2, %block1]
-        %j3 = call int %std.add(int %i3, int %n3)
-        %m3 = call int %std.sub(int %n3, int 1)
-        br label %block1
-    }
-
-Note how the phi nodes correspond to the links in the control flow graph.
-
-List representation
-+++++++++++++++++++
-
-Lists are represented as arrays. The code for the basic operation on lists
-(``getitem``, ``setitem``, ``add``, ``mul``, ``append``, ``pop``...) is
-`written in C`_. This C code is then compiled to LLVM code with the help of
-the LLVM C-front-end. The resulting LLVM code is then transformed (with search
-and replace) to fit in with the rest of GenLLVM. To support lists with
-different types of items the C code implements lists as arrays of pointers to
-``item``, where ``item`` is a dummy struct that is replaced with whatever type
-is wanted.
-
-
-XXX More to come.
-
-
-
-.. _`tiny function`: http://codespeak.net/svn/pypy/dist/pypy/translator/llvm/operations.ll
-.. _`written in C`: http://codespeak.net/svn/pypy/dist/pypy/translator/llvm/list.c
+XXX to be written
 
 .. _`Python again`:
 .. _`Python back-end`:



More information about the Pypy-commit mailing list