2011/2/15 Robert Bradshaw <rober...@math.washington.edu>: > On Tue, Feb 15, 2011 at 2:24 AM, Stefan Behnel <stefan...@behnel.de> wrote: >> Vitja Makarov, 15.02.2011 10:59: >>> 2011/2/15 Stefan Behnel<stefan...@behnel.de>: >>>> Robert Bradshaw, 15.02.2011 08:21: >>>>> >>>>> On Mon, Feb 14, 2011 at 9:49 PM, Vitja Makarov wrote: >>>>>> >>>>>> 2011/2/15 Robert Bradshaw: >>>>>>> >>>>>>> On Sun, Feb 13, 2011 at 11:40 PM, Vitja Makarov wrote: >>>>>>>> >>>>>>>> Hi! >>>>>>>> >>>>>>>> In order to implement "reaching definitions" algorithm. >>>>>>>> I'm now working on control-flow (or data-flow) graph. >>>>>>>> >>>>>>>> Here is funny picture made with graphviz ;) >>>>>>>> >>>>>>>> http://piccy.info/view3/1099337/ca29d7054d09bd0503cefa25f5f49420/1200/ >>>>>>> >>>>>>> Cool. Any plans on handling exceptions? >>>>>> >>>>>> Sure, but I don't have much time for this :( >>>>>> >>>>>> Linear block inside try...except body should be split by assignments >>>>>> and each subblock should point to exception handling entry point. >>>>> >>>>> Would every possible failing sub-expression have to point to the >>>>> exception handling point(s)? >>>> >>> >>> Not sure here as now graph node is list of NameNode ref and AssignmentNode. >>> I'm not sure but it seems that every sub-expression could raise >>> exception now, is there any flag? >>> >>>> Well, in most cases (especially the interesting ones), this will be the >>>> function exit point, so it'll be easy. And in some cases, we may be able to >>>> infer that a specific exception that an expression (e.g. arithmetics or a >>>> 'raise' statement) can raise will not get caught by a given except clause >>>> (although that's certainly a tricky optimisation). >>>> >>>> But in general, I think any subexpression that potentially raises an >>>> exception must point to the next exception handling point. >>>> >>> >>> Right, and each exception handling point should have reference to the >>> next one or function exit point. >>> >>>> >>>>> I suppose it depends on whether you'll be handling more than assignment >>>>> tracking. >>>> >>>> We *may* get away with a statement-level graph in that case, but I somehow >>>> doubt it already. For example, list comprehensions leak their variable in >>>> Py2 code, so it's important to know if they are executed or not, and they >>>> may appear in any kind of expression. >>>> >>> >>> This should be special case for scoped expression node. >>> >>> Now I build graph "from scratch" it include only name node references >>> and assignments, and positions marks to draw gv. >>> >>> May be node tree should be translated into graph and then local >>> variables graph could be created from it. >>> >>> On the other hand CreateAbstractGraph transformation could be used to >>> create specialized graph. >> >> Note that building that graph is only a smaller part of the work. It needs >> to be queriable efficiently. These graphs can easily get huge, so if the >> graph needs to get traversed for each little piece of information, that'll >> seriously slow things down. > > On this note, one thought that I had is that one could traverse the > graph while holding a single state object which nodes could read from > and write to. This would alleviate the need to need to query the graph > and simultaneously store the (large) number of potential states at any > point in the code path. > >> The current (limited) support for control flow analysis initially crashed >> for a beautiful code example that had lots of if-blocks in a row, because >> it was using recursive traversal. I refactored it back then, but he have to >> make sure the new implementation stays scalable. >> >> It's worth reading a bit of literature here. AFAIR, I posted a couple of >> sources to the list a while back. >>
I can push my code into unitialized branch for initial review and criticism. It's rather dirty now but it should be good not to make already known mistakes. -- vitja. _______________________________________________ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
