<div dir="ltr">Hi,<br><br>Thanks for your feedback!<br><br>Yes, I agree. What I described is the "extreme". In a real-world scenario, that may be modified to X amount of time (e.g. days or hours or<br>whatever the programmer believes is important). Automatic tests can be run every X amount of time. You pretty much<br>only have wins, as the module would stay as still otherwise. And if the eternal optimizer breaks something, you can<br>always go back to a previous version.<br><br>My main point is that right now, optimizers are constrained heavily for reasons that might not be pragmatic. Even if the available<br>time becomes an hour vs a minute, imagine how different and more powerful an optimizer could be.<br><br>Best,<br>Stefanos</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Στις Δευ, 13 Απρ 2020 στις 8:33 μ.μ., ο/η Chris Tetreault <<a href="mailto:ctetreau@quicinc.com">ctetreau@quicinc.com</a>> έγραψε:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US">
<div class="gmail-m_3720065331818507678WordSection1">
<p class="MsoNormal">Hi,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">   Seems like something that could be useful, but…<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">> Given that this eternal optimizer will respect the initial semantics, one can compile<br>
> a module, test it, and then let the optimizer do its best. The behavior of a module should<br>
> only be faster, no need to re-test.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">   This seems extremely dangerous. In theory it shouldn’t change the behavior, but all software has bugs…<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thanks,<u></u><u></u></p>
<p class="MsoNormal">   Christopher Tetreault<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><b>From:</b> llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>> <b>On Behalf Of
</b>Stefanos Baziotis via llvm-dev<br>
<b>Sent:</b> Monday, April 13, 2020 9:13 AM<br>
<b>To:</b> llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>Subject:</b> [EXT] [llvm-dev] Why we don't have eternal optimizers?<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">Hi everyone,<br>
<br>
Lately I've been thinking of the optimization model of almost any optimizer ever.<br>
The optimizer should finish "at a reasonable time". For example,<br>
for a 20k lines program, the optimizer should finish in a couple of minutes and not<br>
e.g. a couple of days.<br>
<br>
And my question is, why? For almost all programs, the period that starts when the program<br>
starts being developed to the day it is released is way bigger than a couple of minutes.<br>
In the meantime, a couple of modules might not have been touched for months.<br>
And an unconstrained optimizer could do its best in all this time.<br>
<br>
Given that this eternal optimizer will respect the initial semantics, one can compile<br>
a module, test it, and then let the optimizer do its best. The behavior of a module should<br>
only be faster, no need to re-test.<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">In the meantime of course, we need to test the program as a whole and other modules<br>
might actually change. For that we can already what happens today which is run<br>
"reasonably optimized" builds.<br>
<br>
This is a humble opinion and I'm looking forward to hear the opinion of the LLVM community.<br>
<br>
Best,<br>
Stefanos<u></u><u></u></p>
</div>
</div>
</div>
</div>

</blockquote></div>