Yuval Kogman wrote:

        - optimizers stack on top of each other
        - the output of each one is executable
        - optimizers work in a coroutine, and are preemptable
        - optimizers are small
        - optimizers operate with a certain section of code in mind

> ...
Optimizers get time slices to operate on code as it is needed. They
get small portions - on the first run only simple optimizations are
expected to actually finish.
> ...

A couple of thoughts spring to mind: in these coming times of ubiquitous multi-core computing with software transaction support, perhaps it would be realistic to place optimisation on a low-priority thread. So much code is single-threaded that anything we can do to make use of dual-cores is likely to improve system efficiency.

The other thing that I thought of was the question of errors detected during optimisations. It is possible that an optimiser will do a more in-depth type inference (or dataflow analysis, etc.) and find errors in the code (e.g. gcc -O2 adds warnings for uninitialised variables). This would be a compile-time error that occurs while the code is running. If a program has been running for several hours when the problem is found, what do you do with the error? Would you even want to send a warning to stderr?

Reply via email to