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
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
