[llvm-dev] Why we don't have eternal optimizers?

[Chris Tetreault via llvm-dev]

Hi,

   Seems like something that could be useful, but…

> Given that this eternal optimizer will respect the initial semantics, one can compile
> a module, test it, and then let the optimizer do its best. The behavior of a module should
> only be faster, no need to re-test.

   This seems extremely dangerous. In theory it shouldn’t change the behavior, but all software has bugs…

Thanks,
   Christopher Tetreault

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Stefanos Baziotis via llvm-dev
Sent: Monday, April 13, 2020 9:13 AM
To: llvm-dev <llvm-dev at lists.llvm.org>
Subject: [EXT] [llvm-dev] Why we don't have eternal optimizers?

Hi everyone,

Lately I've been thinking of the optimization model of almost any optimizer ever.
The optimizer should finish "at a reasonable time". For example,
for a 20k lines program, the optimizer should finish in a couple of minutes and not
e.g. a couple of days.

And my question is, why? For almost all programs, the period that starts when the program
starts being developed to the day it is released is way bigger than a couple of minutes.
In the meantime, a couple of modules might not have been touched for months.
And an unconstrained optimizer could do its best in all this time.

Given that this eternal optimizer will respect the initial semantics, one can compile
a module, test it, and then let the optimizer do its best. The behavior of a module should
only be faster, no need to re-test.

In the meantime of course, we need to test the program as a whole and other modules
might actually change. For that we can already what happens today which is run
"reasonably optimized" builds.

This is a humble opinion and I'm looking forward to hear the opinion of the LLVM community.

Best,
Stefanos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200413/4c382db0/attachment.html>