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. > > Stefan > _______________________________________________ > Cython-dev mailing list > Cython-dev@codespeak.net > http://codespeak.net/mailman/listinfo/cython-dev > _______________________________________________ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
