[Cython] Control flow graph

[Vitja Makarov]

2011/2/15 Stefan Behnel <stefan_ml at 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)?
>
> 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.
>
>
>> 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.
>

Hmm... both python and codespeaks in the thread

Here is my commit it's mostly broken now but anyway
https://github.com/vitek/cython/commit/5579b23c3c1c06981331b6427a73e5cb19980b8a


-- 
vitja.