[pypy-dev] More on optimization

Armin Rigo arigo at tunes.org
Wed Nov 3 15:10:21 CET 2004


Hi Holger,

On Tue, Nov 02, 2004 at 07:36:53PM +0100, holger krekel wrote:
> To me the pyrex approach was just a short-cut to produce what your new 
> C-backend now produces directly.

Sure, but the issue under discussion is the next step: how type information
should be used.  The C-backend doesn't use them now.

> 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.

There are two options.  What I called "option 1" is to use the existing
annotation analysis, and then make use of this information in the backends.  
This is a good approach for generating Java code, but maybe not so much for C,
where "option 2" would give better results.  This "option 2" would not use the
existing annotation analysis at all.  Instead, it would replace the
(unannotated) high-level operations with low-level operations and then do a
slightly different kind of analysis on these low-level operations, and finally
the back-end would turn that into C.  As far as I can tell, only "option 2"
can give the best results to translate, say, our W_ListObject class, with its
'ob_item' field containing a list that is "owned" by the W_ListObject instance
and never visible to other parts of the code.

> >    if type(a) is int and type(b) is int:
> >        x = make_int_object(add_long(a.ob_ival, b.ob_ival))
> >    else:
> >        ...
> 
> 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.

No, it's not about merging or not the two flow branches (or the results of the
analysis) after the if/else: in both cases, flow-sensitive or
flow-insensitive, they are merged.  The difference between flow-sensitive and
flow-insensitive is that in the former case, if we discover that we know the
types of a and b statically, then we only explore the first branch (so there
is no merging to be done, because the 2nd branch is never analysed).  This is
what we do currently in our annotations.  By contrast, flow-insensitive
algorithms like the one in the paper Samuele pointed out (or the one done by
Starkiller) don't work like that: they just look at all instructions in the
function and accumulate their possible effects, without worrying about the
control flow.


A bientôt,

Armin



More information about the Pypy-dev mailing list