Hello, Thanks for this work!
Below are a bunch of spelling fixes ;-) On Wed, Apr 25, 2012 at 6:32 PM, Jan Hubicka <hubi...@ucw.cz> wrote: > --- 19,28 ---- > along with GCC; see the file COPYING3. If not see > <http://www.gnu.org/licenses/>. */ > > ! /* This module implements main driver of compilation process. "This module implements the main driver of the compilation process." > The main scope of this file is to act as an interface in between > ! tree based frontends and the backend. s/tree based/GENERIC based/, or leave the 'tree' bit out (is there another kind of front end?). s/frontend/front end/g s/backend/back end/g > The front-end is supposed to use following functionality: s/front-end/front end/ > The function can be called multiple times when multiple source level > ! compilation units are combined. Is this still applicable? I thought -combine was removed. Or is this for things like Fortran modules? > - cgraph_optimize > > ! This passes control to the back-end. Optimizations are performed and s/back-end/back end/ > ! final assembler is generated. This is done in the following way. Note > ! that with link time optimization the process is split into three > ! stages (compile time, linktime analysis and parallel linktime as s/linktime/link time/g > ! indicated bellow). > ! > ! Compile time: > ! > ! 1) Inter-procedural optimization. > ! (ipa_passes) > ! > ! This part is further split into: > ! > ! a) early optimizations. These are local passes executed in > ! the topological order on the callgraph. > ! > ! The purpose of early optimiations is to optimize away simple > ! things that may otherwise confuse IP analysis. Very simple > ! propagation across the callgraph is done i.e. to discover s/i.e./e.g./ > ! functions without side effects and simple inlining is performed. > ! > ! b) early small interprocedural passes. > ! > ! Those are interprocedural passes executed only at compilation > ! time. These include, for exmaple, transational memory lowering, s/exmaple/example/ > ! unreachable code removal and other simple transformations. > ! > ! c) IP analysis stage. All interprocedural passes do their > ! analysis. > ! > ! Interprocedural passes differ from small interprocedural > ! passes by their ability to operate across whole program s/whole program/the whole program/, or "a whole program", or "whole programs". > ! at linktime. Their analysis stage is performed early to > ! both reduce linking times and linktime memory usage by > ! not having to represent whole program in memory. > ! > ! d) LTO sreaming. When doing LTO, everything important gets s/sreaming/streaming/ > ! streamed into the object file. > ! > ! Compile time and or linktime analysis stage (WPA): > ! > ! At linktime units gets streamed back and symbol table is s/units gets/units get/ s/and symbol/and the symbol/ > ! merged. Function bodies are not streamed in and not > ! available. > ! e) IP propagation stage. All IP passes execute their > ! IP propagation. This is done based on the earlier analysis > ! without having function bodies at hand. > ! f) Ltrans streaming. When doing WHOPR LTO, the program > ! is partitioned and streamed into multple object files. s/multple/multiple/ > ! > ! Compile time and/or parallel linktime stage (ltrans) > > + Each of the object files is streamed back and compiled > + separately. Now the function bodies becomes available > + again. > + > + 2) Virtual clone materialization > + (cgraph_materialize_clone) > + > + IP passes can produce copies of existing functoins (such s/functoins/functions/ > + as versioned clones or inline clones) without actually > + manipulating their bodies by creating virtual clones in > + the callgraph. At this time the virtual clones are > + turned into real functions add newline > + 3) IP transformation > + > + All IP passes transform function bodies based on earlier > + decision of the IP propagation. > + > + 4) late small IP passes > + > + Simple IP passes working within single program partition. > + > + 5) Expansion > + (cgraph_expand_all_functions) > + > + At this stage functions that needs to be output into s/needs/need/ > + assembler are identified and compiled in topological order s/order/order./ add newline > + 6) Output of variables and aliases > + Now it is known what variable references was not optimized s/references was not/references were not/ > + out and thus all variables are output to the file. > + > + Note that with -fno-toplevel-reorder passes 5 and 6 > + are combined together in cgraph_output_in_order. > + > + Finally there are functions to manipulate the callgraph from s/from/from the/ > + backend. > + - cgraph_add_new_function is used to add backend produced s/backend/back-end/ > + functions introduced after the unit is finalized. > + The functions are enqueue for later processing and inserted > + into callgraph with cgraph_process_new_functions. s/into/into the/ > + > + - cgraph_function_versioning > + > + produces a copy of function into new one (a version) > + and apply simple transformations s/apply/applies/ or s/produces/produce/ Ciao! Steven
