[Cython] Fused Types

[Stefan Behnel]

mark florisson, 02.05.2011 11:22:
> On 2 May 2011 11:08, Stefan Behnel wrote:
>> Robert Bradshaw, 30.04.2011 08:16:
>>>
>>> On Fri, Apr 29, 2011 at 8:04 AM, mark florisson
>>>>
>>>> With the type matching it matches on exactly 'if src_type is
>>>> dst_type:' so you can't use 'and' and such... perhaps I should turn
>>>> these expression into a node with the constant value first and then
>>>> see if the result of the entire expression is known at compile time?
>>>
>>> Yes, that's exactly what I was thinking you should do.
>>
>> For now, you could simply (try to) re-run the ConstantFolding transform
>> after the type splitting. It will evaluate constant expressions and also
>> drop unreachable branches from conditionals.
>
> Right thanks! I actually ran it on the condition only, as I overlooked
> its branch pruning capability (sometimes I see 'if (1)' generated
> code, so that's probably because that happens after ConstantFolding).

... or because something generates that explicitly (e.g. to simplify some 
specific code generation), but I couldn't find this with a quick grep right 
now. I once put a C for-loop into straight sequential argument unpacking 
code, so that I could "break" out of it at any point, rather than using 
gotos and labels for that. But that was only half-way hackish because that 
particular code mimics an unrolled loop anyway.

In the future, Vitja's dead code removal branch will handle branch pruning 
anyway. I just put it into the ConstantFolding transform at the time as it 
fit in there quite well, and because I thought it would help also during 
the constant calculation to get rid of dead code while we're at it, e.g. in 
conditional expressions (x if c else y) or later on in combination with 
things like the FlattenInList/SwitchTransform.


> So wouldn't it be a good idea to just insert another ConstantFolding
> transform at the end of the pipeline also, and have it recalculate
> constants in case it was previously determined not_a_constant?

An additional run would also make sense before the optimisation steps that 
run after type analysis. Some of them can take advantage of constants, 
including those created before and during type analysis. Maybe even a third 
run right before the code generation, i.e. after the optimisations.

Not sure if "not_a_constant" values can become a problem. They'll be 
ignored in the next run, only "constant_value_not_set" values will be 
recalculated. While newly created expressions will usually be virgins, new 
values/expressions that are being added to existing "not_a_constant" 
expressions may end up being ignored, even if the whole expression could 
then be condensed into a constant.

OTOH, these cases may be rare enough to not deserve the additional 
performance penalty of looking at all expression nodes again. It may be 
better to call back into ConstantFolding explicitly when generating 
expressions at a later point, or to just calculate and set the constant 
values properly while creating the nodes.

While you're at it, you can test if it works to reuse the same transform 
instance for all runs. That should be a tiny bit quicker, because it only 
needs to build the node dispatch table once (not that I expect it to make 
any difference, but anyway...).

Stefan