On 2 May 2011 12:32, Stefan Behnel <stefan...@behnel.de> wrote: > 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.
Right, in my branch I introduced a new instance variable, and if that's true it ignores "not_a_constant" and tries to compute it anyway, as the pruning is mandatory and at the expression was determined "not_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. So far (from what I've seen, I haven't actually done any benchmarks) I think the C compiler is still like 5 times as slow as Cython. > 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...). Ok, sure. > Stefan > _______________________________________________ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel > _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
