<div dir="ltr"><div>Yes, that's true, but I believe that such decisions should offered 
to the programmers rather than dictated.  There is also a whole other 
discussion on<br><br>* how/where optimizations/transformations could  be recorded<br>* how tracebacks could be handled<br></div><div>* debugging optimized code <br><br></div>But
 here I wanted to focus on just the optimization interaction. If you are
 implying that pypy doesn't do changes that would make such behaviorial 
changes, then that would suggest there may be a lot of benefit static 
compiler optimization. </div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jul 9, 2017 at 9:41 PM, <a href="mailto:rymg19@gmail.com">rymg19@gmail.com</a> <span dir="ltr"><<a href="mailto:rymg19@gmail.com" target="_blank">rymg19@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id="m_1115704415462564271edo-message"><div>Part of the problem is behavioral changes. If you implement tail call recursion, your tracebacks change. Common subexpression elimination will also have subtle behavioral changes.<br><br><br><div id="m_1115704415462564271edo-signature"><pre>--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
<a href="http://refi64.com" target="_blank">http://refi64.com</a></pre></div></div></div><div id="m_1115704415462564271edo-original"><div><blockquote type="cite"><div><div class="h5"><div id="m_1115704415462564271edo-meta">On Jul 9, 2017 at 8:11 PM, <<a href="mailto:rb@dustyfeet.com" target="_blank">Rocky Bernstein</a>> wrote: <br><br></div><div dir="ltr"><div><div><div><div><div><div><div>In looking at Python bytecode over the years, I've noticed that it does very little to no traditional static-compiler optimization. Specifically: <br><br></div>* Dead code elmination (most of the time)<br></div>* Jumps to Jumps or Jumps to the next instruction<br></div>* Constant propagation (most of the time)<br></div>* Common subexpression elimination<br></div>* Tail recursion<br></div>* Code hoisting/sinking <br><br></div><div>Yes, over the years more compiler optimization has been done but it's still pretty sparse. <br></div><div><br></div><div>The little that I've looked at pypy, it is pretty much the same thing at the Python bytecode level. That's why a python decompiler for say 2.7 will work largely unmodified for he corresponding pypy 2.7 version. Same is true 3.2 versus pypy 3.2. <br><br></div><div>I understand though that pypy can do and probably does some of the optimization when it JITs. But my question is: if traditional compiler optimization were done would this hinder, be neutral, or help pypy's optimization. <br><br></div><div>Of course, if there were static compiler optimization of the type described above, that might be a win when JITing doesn't kick in. (And perhaps then who cares) <br><br></div><div>But I'm interested in the other situation where both are in play. <br></div></div></div></div>
______________________________<wbr>_________________
pypy-dev mailing list
<a href="mailto:pypy-dev@python.org" target="_blank">pypy-dev@python.org</a>
<a href="https://mail.python.org/mailman/listinfo/pypy-dev" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/pypy-dev</a>
</blockquote></div></div>
</blockquote></div><br></div>