[Cython] Control flow graph

[Vitja Makarov]

2011/2/28 Vitja Makarov <vitja.makarov at gmail.com>:
> 2011/2/23 Vitja Makarov <vitja.makarov at gmail.com>:
>> 2011/2/23 Vitja Makarov <vitja.makarov at gmail.com>:
>>> 2011/2/22 Stefan Behnel <stefan_ml at behnel.de>:
>>>> Vitja Makarov, 20.02.2011 18:23:
>>>>>
>>>>> 2011/2/16 Vitja Makarov:
>>>>>>
>>>>>> Hmm... both python and codespeaks in the thread
>>>>
>>>> Yes, we should keep it to cython-devel only. Sorry for mixing it up.
>>>>
>>>>
>>>>>> Here is my commit it's mostly broken now but anyway
>>>>>>
>>>>>> https://github.com/vitek/cython/commit/5579b23c3c1c06981331b6427a73e5cb19980b8a
>>>>
>>>> Flow control support is large enough to merit its own module. Not sure how
>>>> 'smart' git is here, but you can always keep the history by explicitly
>>>> copying ParseTreeTransforms.py to FlowControl.py and removing the unrelated
>>>> sections from both files.
>>>>
>>>
>>> Ok.
>>>
>>
>> Oops there is no copy command in git.
>>
>>
>>>> You are duplicating some code from the type inferencer. We might want to
>>>> clean that up at some point. However, given that flow control analysis will
>>>> allow us to improve the type inferencer, I think it's best to keep this code
>>>> in the FCA part.
>>>>
>>>
>>> Yes, I think it could replace MarkAssignments transform later.
>>> Unreachable code could be delete there too.
>>>
>>>>
>>>>> I've update stuff:
>>>>>  - algo for finding definitions
>>>>>  - warnings for uninitialized and may be uninitialised use
>>>>>  - few test cases
>>>>
>>>> That looks very nice so far. Any idea how well it scales?
>>>>
>>>
>>> "Usually iterative algorithm takes no more then 5 iterations"
>>>
>>> For ExprNodes.py max number is 15 while avg is about 3
>>>
>>> About execution time:
>>>
>>> ExprNodes.py compilation with c/f enabled takes 10.120 ms, w/o 9.325,
>>> ~10% slow down.
>>> -O flag could be introduced but I don't think that's a good idea.
>>>
>>> Should later try to execute cython compiled code.
>>>
>>>>
>>>>> Trying to compile ParseTreeTransforms.py I've found this for example:
>>>>>
>>>>> warning: Cython/Compiler/ParseTreeTransforms.py:1182:27: Variable
>>>>> 'template' may be used uninitialized
>>>>>
>>>>>     def create_Property(self, entry):
>>>>>         if entry.visibility == 'public':
>>>>>             if entry.type.is_pyobject:
>>>>>                 template = self.basic_pyobject_property
>>>>>             else:
>>>>>                 template = self.basic_property
>>>>>         elif entry.visibility == 'readonly':
>>>>>             template = self.basic_property_ro
>>>>>         property = template.substitute({
>>>>>                 u"ATTR": ExprNodes.AttributeNode(pos=entry.pos,
>>>>>
>>>>> obj=ExprNodes.NameNode(pos=entry.pos, name="self"),
>>>>>                                                  attribute=entry.name),
>>>>>             }, pos=entry.pos).stats[0]
>>>>
>>>> Ok, I guess that code generally works, but it's better to get rid of the
>>>> code smell.
>>>>
>>>
>>> Might be used warning should be disabled by default, because algorithm
>>> isn't smart enough:
>>>
>>> a = 1
>>> if (a): b = 1
>>> if (a): print b
>>>
>>> See also:
>>> http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wuninitialized-325
>>>
>
>
> I've updated things:
>
>  - Now it passes all the tests (some tests are run with
> remove_unreachable=False)
>  - Control flow graph support all the control statements (hope so)
>  - Analyse PyClassDefNode (now only inner, need some more work)
>  - Now we have the following optional warnings:
>  1. uninitialized variable use [default on]
>  2. possibly uninitialized use [-Wextra]
>  3. unreachable code [default on] (this needs rework, unreachable
> code detection could be better handled inside CreateControlFlowGraph)
>  4. unused variable [-Wextra]
>  5. unused argument [-X warn.unused_arg=True]
>  6. unused result [-X warn_unused_result=True]
>
>  - Optional dot graph output:
>
>  $ cython foo.pyx -X control_flow.dot_output=foo.dot
>  $ dot -Tpng -o foo.png foo.dot
>

I've pushed unused varaiable/result removal.
Unused argument removal require some more work, especially generic
args and kwargs.

Now I'm going to handle local variable deletion and then remove
Py_None initialization.

-- 
vitja.