2011/3/14 Alexander Belopolsky <span dir="ltr">&lt;<a href="mailto:alexander.belopolsky@gmail.com">alexander.belopolsky@gmail.com</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Sat, Mar 12, 2011 at 1:08 PM, Raymond Hettinger<br>
&lt;<a href="mailto:raymond.hettinger@gmail.com">raymond.hettinger@gmail.com</a>&gt; wrote:<br>
&gt; I would like to withdraw my suggestion for the recursive constant folding patch to be reverted.<br>
<br>
</div>So what is the status of peephole optimization now?  Is it back under<br>
active development?   Let me quote a tracker comment that I posted two<br>
years ago and go no response to (&#39;&gt;&#39;-quote are from Raymond&#39;s<br>
message):<br>
<br>
&quot;&quot;&quot;<br>
Constant folding promotes more readable code: 24*60*60 is more obvious<br>
than 86400, prefixing positive numbers with + leads to better visual<br>
alignment, etc.  Users should not be required to think twice about<br>
which constant expressions are folded and which are not.<br>
<br>
Here is another surprise with the current peepholer:<br>
<div class="im"><br>
&gt;&gt;&gt; dis(lambda:1+2*3)<br>
</div>  1           0 LOAD_CONST               0 (1)<br>
              3 LOAD_CONST               3 (6)<br>
              6 BINARY_ADD<br>
              7 RETURN_VALUE<br>
<br>
&gt;&gt;&gt; dis(lambda:2*3+1)<br>
  1           0 LOAD_CONST               4 (7)<br>
              3 RETURN_VALUE<br>
<br>
I have a fix in the works, but I will wait for your further comments<br>
before submitting it.<br>
<br>
&gt;<br>
&gt;  More importantly, we decided that the peepholer is the wrong place to<br>
&gt;  do much of this work.  Most of the peepholer is going to be migrated<br>
&gt;  up the chain, after the AST is generated, but before the opcodes are<br>
&gt;  generated.  That is a faster, more reliable, and more general<br>
&gt;  approach.<br>
&gt;<br>
<br>
I agree.   Constant folding, is an interesting case because peepholer<br>
has to duplicate a subset of eval logic.  I wonder if the new approach<br>
could eliminate that.<br>
</blockquote><div><br></div><div>I followed a different approach. Constant folding in WPython is made between ASDL evalutation and AST building.<br></div><div><br></div><div>The idea is to &quot;intercept&quot; constant values and apply the operations generating a new value instead of generating the classic AST node (a BinOp for a binary operation, for example).</div>
<div><br></div><div>This way there&#39;s no need to parse the AST tree seeking for cases where to apply the constant folding logic.</div><div><br></div><div>It&#39;s faster, because you don&#39;t need an additional pass through the AST: you&#39;ll do it while building the AST...</div>
<div><br></div><div>It consumes less memory too, since you don&#39;t need to generate complex AST nodes that must be discarded after applying the folding (which generates new nodes). Think about a tuple of constant values, for example: you have to generate a Tuple AST structure from the ASDL, then an AST constant folder will generate the tuple. In WPython the tuple is generated immediately, directly from the ADSL seq structure.</div>
<div><br></div><div>It&#39;s also efficient, since expressions such as 1 + 2 * 3 can be completely folded generating 7, instead of 1 + 6 of the (classic) peepholer. That&#39;s because, when parsing the ASDL structures, nodes are evaluated in respect of operator precedence, so first we evaluate 2 * 3, which produces 6 applying the folding, and then 1 + 6, which produces 7 in the end.</div>
<div><br></div><div>Cesare</div>