Hi, I started working on ticket #119, which deals with constant folding and figuring out at code generation time if a subexpression is constant. An initial implementation is here:
http://hg.cython.org/cython-devel/rev/8a2e7b51e770 It happily borrows from the compile_time_value() evaluation which is done at parse time, but moves it into a separate ConstantFolding transform (which runs after type analysis). This makes it a lot simpler to calculate the result in a node method, as all the error handling and preconditions are now handled in the transform code. The constant result is stored in node.constant_result, which is set to ExprNodes.not_a_constant if the result cannot be determined. Apart from slowing down the compilation a bit, the transform does not yet have *any* impact on code generation :). It does not replace any nodes with a ConstNode, neither does the code generation phase use the results so far. Replacing a node requires knowing which node can represent the type of the expression, which needs to be defined first, but which would have the best impact on code generation and transforms later in the pipeline. Being able to read the constant result from any node might however be just as useful during code generation. I also skipped any name lookups so far, so constant calculation is currently mostly restricted to arithmetic expressions and builtin type literals (lists, tuples, dicts, sets). It's also tested very little, there's a tiny run/consts.pyx test, which will only get interesting once we generate optimised code for calculated constants. At least, building up the constant values at compile time doesn't break lxml's build so far. :) Any use cases and further hacking appreciated. :) Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
