Author serhiy.storchaka
Recipients benjamin.peterson, brett.cannon, inada.naoki, ncoghlan, pitrou, rhettinger, serhiy.storchaka, yselivanov
Date 2018-01-03.21:37:25
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1515015445.92.0.467229070634.issue32477@psf.upfronthosting.co.za>
In-reply-to
Content
Actually moving any of remaining optimizations (including two optimizations that are moved by this issue and two other that are left) slightly increases the complexity. But instead the optimizations become more general. At the end, after moving all optimizations, we could drop the auxiliary code in the peepholer (building the table of basic blocks, removing NOPs, fixing up jump targets) and the net complexity will be reduced. This can also reduce the time and memory consumption of compilation.

Thus getting rid of the peepholer optimizer working with the bytecode is my goal. But some peephole optimizations will work with the intermediate fixed-size representations used by the compiler, before generating the concrete bytecode.
History
Date User Action Args
2018-01-03 21:37:25serhiy.storchakasetrecipients: + serhiy.storchaka, brett.cannon, rhettinger, ncoghlan, pitrou, benjamin.peterson, inada.naoki, yselivanov
2018-01-03 21:37:25serhiy.storchakasetmessageid: <1515015445.92.0.467229070634.issue32477@psf.upfronthosting.co.za>
2018-01-03 21:37:25serhiy.storchakalinkissue32477 messages
2018-01-03 21:37:25serhiy.storchakacreate