Author ncoghlan
Recipients benjamin.peterson, brett.cannon, methane, ncoghlan, pitrou, rhettinger, serhiy.storchaka, yselivanov
Date 2018-04-21.05:29:50
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1524288592.19.0.682650639539.issue33318@psf.upfronthosting.co.za>
In-reply-to
Content
If I recall Eugene Toder's previous AST-level compilation patches correctly, they handle this problem by putting the AST optimisation step *after* the output of the Py_CF_ONLY_AST step.

This meant that if you're running the source->AST step explicitly, you still get the original unoptimised AST out, which is what you actually want for a lot of source-code-analysis-or-manipulation related use cases.

The optimisation steps then all remained in the "AST -> executable opcodes" phase, they were just structured a bit differently due to the addition of an extra step (AST -> optimised AST -> executable opcodes -> optimised opcodes).

This is more work initially (since it involves building out a completely new compiler pass for the "AST -> optimised AST" step), but means that:

* existing source->AST use cases are unaffected by the compiler change
* existing AST->opcode use cases continue to benefit from all of the optimisation passes, regardless of whether those optimisations are applied at the AST or opcode level
History
Date User Action Args
2018-04-21 05:29:52ncoghlansetrecipients: + ncoghlan, brett.cannon, rhettinger, pitrou, benjamin.peterson, methane, serhiy.storchaka, yselivanov
2018-04-21 05:29:52ncoghlansetmessageid: <1524288592.19.0.682650639539.issue33318@psf.upfronthosting.co.za>
2018-04-21 05:29:52ncoghlanlinkissue33318 messages
2018-04-21 05:29:50ncoghlancreate