[pypy-dev] CLI code generation (was: Svn account?)

holger krekel hpk at trillke.net
Mon Mar 20 14:19:32 CET 2006


Hi Antonio! 

On Mon, Mar 20, 2006 at 10:52 +0100, Antonio Cuni wrote:
> holger krekel wrote:
> >Hi Antonio, 
> >
> >On Sun, Mar 19, 2006 at 20:53 +0100, Antonio Cuni wrote:
> >>as I said I've begun writing the .NET CLI backend; it is still very 
> >>experimental but it can already compile correctly some code snippets 
> >>such as the algorithm for computing fibonacci's numbers.
> >
> >cool!  I would be interested to hear a bit more about your concrete
> >current approach. 
> 
> I respond here so that other can read, if they are interested.

sure! that was the idea :) 

> The first decision I took is whether to generate IL code (to be 
> assembled with ilasm) or C# code: I choose the first mainly because C# 
> lacks the goto statement and it would be difficult to implement flow 
> control.

makes sense. 

What you left out is: where did you start from?  the llvm or genc backend
i guess?  

> Given this, my current approach if fairly naive and certainly not 
> efficient: at the moment the compiler does a 1-to-1 translation between 
> low level operation expressed in SSA; for example the simple function:
> 
> def bar(a,b):
>     return a+b
> 
> is compiled into the following IL code:
> 
> .method static public int32 bar(int32 a_1, int32 b_1) il managed
> {
>     .locals (int32 v6, int32 v12)
> 
> block0:
>     ldarg.s 'a_1'
>     ldarg.s 'b_1'
>     add
>     stloc.s 'v12'
>     ldloc.s 'v12'
>     stloc.s 'v6'
>     br.s block1
> 
> block1:
>     ldloc.s 'v6'
>     ret
> }
> 
> As you can see there are many unnecessary operations: the result of 
> 'add' is stored to v12, loaded from v12, stored in v6 and then loaded 
> from v6! The same is true for the branch instruction, which is unneeded.
> I think it should be fairly simple to translate from the SSA form to a 
> more "stack-friendly" form useful for stack-based machines; the question 
> is: where to put such code?

You need probably not worry about these optimizations - i am sure
that the CLR takes care of that so it shouldn't reduce in a
speed penalty (most of the time). 

But if you want to do it then i suggest the same directory
structure as "pypy/translator/llvm", maybe a "backendopt"
directory where you put the graph transformation. 

> Since it could be useful even for other backends, it would be nice to 
> put it in some place where it can be shared from several backends: one 
> option could be to write it as a backend optimization, but in this case 
> we have to introduce new low level operations for stack manipulation, 
> such as 'push', 'pop' or 'dup'.

With the new operations it becomes probably a final step before
the actual code generation.  If this proves to be generally useful 
(might well be) we can move it from a the IL directory to the common
"pypy/translator/backendopt" (and maybe rename the directory to account
for optimizations as well as transformations for other purposes). 

cheers, 

    holger



More information about the Pypy-dev mailing list