gccint: Parsing pass

1 
1 9.1 Parsing pass
1 ================
1 
1 The language front end is invoked only once, via
1 'lang_hooks.parse_file', to parse the entire input.  The language front
1 end may use any intermediate language representation deemed appropriate.
1 The C front end uses GENERIC trees (⇒GENERIC), plus a double
1 handful of language specific tree codes defined in 'c-common.def'.  The
1 Fortran front end uses a completely different private representation.
1 
1  At some point the front end must translate the representation used in
1 the front end to a representation understood by the language-independent
1 portions of the compiler.  Current practice takes one of two forms.  The
1 C front end manually invokes the gimplifier (⇒GIMPLE) on each
1 function, and uses the gimplifier callbacks to convert the
1 language-specific tree nodes directly to GIMPLE before passing the
1 function off to be compiled.  The Fortran front end converts from a
1 private representation to GENERIC, which is later lowered to GIMPLE when
1 the function is compiled.  Which route to choose probably depends on how
1 well GENERIC (plus extensions) can be made to match up with the source
1 language and necessary parsing data structures.
1 
1  BUG: Gimplification must occur before nested function lowering, and
1 nested function lowering must be done by the front end before passing
1 the data off to cgraph.
1 
1  TODO: Cgraph should control nested function lowering.  It would only be
1 invoked when it is certain that the outer-most function is used.
1 
1  TODO: Cgraph needs a gimplify_function callback.  It should be invoked
1 when (1) it is certain that the function is used, (2) warning flags
1 specified by the user require some amount of compilation in order to
1 honor, (3) the language indicates that semantic analysis is not complete
1 until gimplification occurs.  Hum... this sounds overly complicated.
1 Perhaps we should just have the front end gimplify always; in most cases
1 it's only one function call.
1 
1  The front end needs to pass all function definitions and top level
1 declarations off to the middle-end so that they can be compiled and
1 emitted to the object file.  For a simple procedural language, it is
1 usually most convenient to do this as each top level declaration or
1 definition is seen.  There is also a distinction to be made between
1 generating functional code and generating complete debug information.
1 The only thing that is absolutely required for functional code is that
1 function and data _definitions_ be passed to the middle-end.  For
1 complete debug information, function, data and type declarations should
1 all be passed as well.
1 
1  In any case, the front end needs each complete top-level function or
1 data declaration, and each data definition should be passed to
1 'rest_of_decl_compilation'.  Each complete type definition should be
1 passed to 'rest_of_type_compilation'.  Each function definition should
1 be passed to 'cgraph_finalize_function'.
1 
1  TODO: I know rest_of_compilation currently has all sorts of RTL
1 generation semantics.  I plan to move all code generation bits (both
1 Tree and RTL) to compile_function.  Should we hide cgraph from the front
1 ends and move back to rest_of_compilation as the official interface?
1 Possibly we should rename all three interfaces such that the names match
1 in some meaningful way and that is more descriptive than "rest_of".
1 
1  The middle-end will, at its option, emit the function and data
1 definitions immediately or queue them for later processing.
1