Editing Optimizing compiler (section)

== Practical considerations ==
There can be a wide range of optimizations that a compiler can perform, ranging from simple and straightforward optimizations that take little compilation time to elaborate and complex optimizations that involve considerable amounts of compilation time.<ref name="aho-sethi-ullman" />{{rp|page=15}} Accordingly, compilers often provide options to their control command or procedure to allow the compiler user to choose how much optimization to request; for instance, the IBM FORTRAN H compiler allowed the user to specify no optimization, optimization at the registers level only, or full optimization.<ref name="aho-sethi-ullman" />{{rp|page=737}} By the 2000s, it was common for compilers, such as [[Clang]], to have several compiler command options that could affect a variety of optimization choices, starting with the familiar <code>-O2</code> switch.<ref>{{cite web|url=https://developers.redhat.com/blog/2019/08/05/customize-the-compilation-process-with-clang-optimization-options/|title=Customize the compilation process with Clang: Optimization options|author-first=Serge|author-last=Guelton|publisher=Red Hat|date=August 5, 2019}}</ref>

An approach to isolating optimization is the use of so-called [[post-pass optimizer]]s (some commercial versions of which date back to mainframe software of the late 1970s).<ref>{{cite journal|author=Evans|first=Michael|date=December 1982|title=Software engineering for the Cobol environment|url=https://dl.acm.org/doi/10.1145/358728.358732|journal=[[Communications of the ACM]]|volume=25|issue=12|pages=874–882|doi=10.1145/358728.358732|access-date=2013-08-10}}</ref> These tools take the executable output by an optimizing compiler and optimize it even further. Post-pass optimizers usually work on the [[assembly language]] or [[machine code]] level (in contrast with compilers that optimize intermediate representations of programs). One such example is the [[Portable C Compiler]] (PCC) of the 1980s, which had an optional pass that would perform post-optimizations on the generated assembly code.<ref name="aho-sethi-ullman" />{{rp|page=736}}

Another consideration is that optimization algorithms are complicated and, especially when being used to compile large, complex programming languages, can contain bugs that introduce errors in the generated code or cause internal errors during compilation. Compiler errors of any kind can be disconcerting to the user, but especially so in this case, since it may not be clear that the optimization logic is at fault.<ref>{{cite conference|url=https://dl.acm.org/citation.cfm?id=2931074&CFID=827491623&CFTOKEN=57038897|first=Chengnian|display-authors=et al|last=Sun|book-title=Proceedings of the 25th International Symposium on Software Testing and Analysis|title=Toward understanding compiler bugs in GCC and LLVM|date=July 18–20, 2016|pages=294–305| doi=10.1145/2931037.2931074|isbn=9781450343909|conference=Issta 2016|s2cid=8339241}}</ref> In the case of internal errors, the problem can be partially ameliorated by a "fail-safe" programming technique in which the optimization logic in the compiler is coded such that a failure is trapped, a warning message issued, and the rest of the compilation proceeds to successful completion.<ref>{{cite journal|title=Fail-safe programming in compiler optimization|first=Jonathan L.|last=Schilling|journal=ACM SIGPLAN Notices|volume=28|issue=8|date=August 1993|pages=39–42|doi=10.1145/163114.163118| s2cid=2224606}}</ref>