[pypy-dev] More on optimization

[holger krekel]

Hi Armin, hi Samuele, 

[Armin Rigo Tue, Nov 02, 2004 at 04:19:05PM +0000]
> So LLVM comes again under the focus; we should really give it a serious try at
> some point.

indeed.  We may also give joeq (http://joeq.sourceforge.net) a look although
development seems to be stalled. 

> There are clearly two point of views that we can take on RPython.  The first
> point of view is that RPython is a kind of nice syntax over a C- or Java-like
> language (in this view integers are primitive, and type inference is used to
> fill in the missing type declarations).  The alternative is to see RPython as
> semantically close to Python, and all the variables contain objects, but we
> can obtain better performance via optimization.  The current
> annotation-and-Pyrex-or-Lisp approach follows the 1st approach, but I feel
> like the 2nd one can give better results.  Well, I guess you guessed :-)

To me the pyrex approach was just a short-cut to produce what your new 
C-backend now produces directly.  
 
> Let me try to explore a few consequences of such a choice. A general critique
> I have regarding a lot of research (including the paper you cited) is that the
> techniques are flow-insensitive.

the choice of the backend should not influence the flow/annotation analysis, 
should it? I guess i don't see the connection you seem to imply 
between these two parts of the translation process.  

> I'm not sure if it is a problem for the 1st
> approach but it is for the 2nd one: the low-level flow graph of, say, "a+b"
> is:
> 
>    if type(a) is int and type(b) is int:
>        x = make_int_object(add_long(a.ob_ival, b.ob_ival))
>    else:
>        ...
> 
> It is essential to follow the exact control path in this function, which tells
> us that a and b only have a field 'ob_ival' to read when they are actually of
> type int.

Does this relate to a previous idea of generating two flow branches for
the above if/else that would not get merged at the next point 
after the if/else?  IIRC, we currently merge the "framestates" right
after the if/else. 

cheers, 

    holger