[Cython] Control flow graph

Vitja Makarov vitja.makarov at gmail.com
Mon Feb 28 21:30:15 CET 2011


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

-- 
vitja.


More information about the cython-devel mailing list