Robert Bradshaw, 16.07.2010 06:06: > On Thu, Jul 15, 2010 at 8:52 PM, Stefan Behnel wrote: >> Robert Bradshaw, 16.07.2010 04:59: >>> Hopefully a simple kind of common subexpression elimination could >>> remove the redundant coercions (as well as help out in a lot of other >>> places). >> >> You can't really do common subexpression elimination on Python code as even >> operators may have side effects. You can't even know if there may be *no* >> be side effects before the type analysis tells you that you are only >> dealing with plain C values. > > The common subexpression elimination would happen at a much later > stage in the pipeline.
Ah, right, you were really only talking about reducing coercions by doing them once and reusing the result. That might work, yes. So it's not true CSE in the sense of really working on expressions but rather something at a NameNode/temps level. > I trust gcc to do an OK job for pure C values, > but we should be able to assert C value -> Python value is side-effect > free at least. That way, yes. The other way, no. And that's a problem already if you don't know the types at the time where you transform the code. Some of the required information might be available after the analyse_declarations phase, though. >> No, I think the only way to deal with this early enough is to introduce a >> ReusedExpression node, and to handle that basically everywhere, also during >> type analysis. We currently do a lot of node type checks in the optimiser, >> so we'll need a better way to deal with that, too. > > We had CloneNode, how would ReusedExpressionNode be better? Well, we need some kind of specific node that lets us know that an expression is reused, so that temp handling, ref-counting and your proposed coercion removal can do the right thing. Either that, or a larger reworking in ExprNodes.py to support reusing arbitrary expression results in different places, which currently is impossible due to the way temp handling works. > (Also, I don't see how it would help with types.) You'd special case it during type analysis in that its type is only determined after evaluating all occurrences, and then is set to the most efficient type for all use patterns that minimises the number of coercions. However, I think this can't easily be done with the current evaluate-once flow of type analysis. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
