compiler - yszheda/wiki GitHub Wiki
Frontend Parser
Optimization
(N)RVO
-
https://docs.microsoft.com/en-us/cpp/build/reference/o1-o2-minimize-size-maximize-speed?view=vs-2017
LTCG (Link-time Code Generation)
The Normal Build Process
backend compiler: boundary conditions and lack of knowledge
-
An example of a boundary condition is when one function calls another function in a different source file. Because the compiler has limited knowledge of what the other function looks like, it has to rely on calling conventions to ensure it's called correctly. While the use of calling conventions ensures a certain level of safety, they also potentially add to the amount of code generated. To ensure that the calling conventions are adhered to, the code generator may need to add additional instructions that might not be absolutely necessary.
-
Another example of when lack of knowledge hinders the optimizer occurs with function inlining.
Link-time Code Generation
When the linker is invoked with IL-based OBJ files, it calls COM methods in the back end (C2.DLL) to generate the final, processor-specific code. When the linker invokes the back end, it gives the back end all of the IL from all the OBJs (as well as any pregenerated code like you might find in a .LIB file.) Because the code generator now has almost perfect knowledge of the code, it can be much more aggressive when it optimizes.
It's worth noting that the neither the linker nor the compiler back end got significantly smarter here. The major work in implementing LTCG was the juggling required to allow the back end to be called from either the front end or from the linker. The linker also was smartened up so that it could work with a combination of IL-based OBJ files and normal OBJ and LIB files already containing actual code.
- https://docs.microsoft.com/en-us/cpp/build/reference/ltcg-link-time-code-generation?view=vs-2017
- What are the pros + cons of Link-Time Code Generation? (VS 2005)