]>
Commit | Line | Data |
---|---|---|
c63539ff ML |
1 | .. |
2 | Copyright 1988-2022 Free Software Foundation, Inc. | |
3 | This is part of the GCC manual. | |
4 | For copying conditions, see the copyright.rst file. | |
5 | ||
6 | .. index:: GENERIC, lang_hooks.parse_file | |
7 | ||
8 | .. _parsing-pass: | |
9 | ||
10 | Parsing pass | |
11 | ************ | |
12 | ||
13 | The language front end is invoked only once, via | |
14 | ``lang_hooks.parse_file``, to parse the entire input. The language | |
15 | front end may use any intermediate language representation deemed | |
16 | appropriate. The C front end uses GENERIC trees (see :ref:`generic`), plus | |
17 | a double handful of language specific tree codes defined in | |
18 | :samp:`c-common.def`. The Fortran front end uses a completely different | |
19 | private representation. | |
20 | ||
21 | .. index:: GIMPLE, gimplification, gimplifier, language-independent intermediate representation, intermediate representation lowering, lowering, language-dependent intermediate representation | |
22 | ||
23 | At some point the front end must translate the representation used in the | |
24 | front end to a representation understood by the language-independent | |
25 | portions of the compiler. Current practice takes one of two forms. | |
26 | The C front end manually invokes the gimplifier (see :ref:`gimple`) on each function, | |
27 | and uses the gimplifier callbacks to convert the language-specific tree | |
28 | nodes directly to GIMPLE before passing the function off to be compiled. | |
29 | The Fortran front end converts from a private representation to GENERIC, | |
30 | which is later lowered to GIMPLE when the function is compiled. Which | |
31 | route to choose probably depends on how well GENERIC (plus extensions) | |
32 | can be made to match up with the source language and necessary parsing | |
33 | data structures. | |
34 | ||
35 | BUG: Gimplification must occur before nested function lowering, | |
36 | and nested function lowering must be done by the front end before | |
37 | passing the data off to cgraph. | |
38 | ||
39 | .. todo:: Cgraph should control nested function lowering. It would | |
40 | only be invoked when it is certain that the outer-most function | |
41 | is used. | |
42 | ||
43 | .. todo:: Cgraph needs a gimplify_function callback. It should be | |
44 | invoked when (1) it is certain that the function is used, (2) | |
45 | warning flags specified by the user require some amount of | |
46 | compilation in order to honor, (3) the language indicates that | |
47 | semantic analysis is not complete until gimplification occurs. | |
48 | Hum... this sounds overly complicated. Perhaps we should just | |
49 | have the front end gimplify always; in most cases it's only one | |
50 | function call. | |
51 | ||
52 | The front end needs to pass all function definitions and top level | |
53 | declarations off to the middle-end so that they can be compiled and | |
54 | emitted to the object file. For a simple procedural language, it is | |
55 | usually most convenient to do this as each top level declaration or | |
56 | definition is seen. There is also a distinction to be made between | |
57 | generating functional code and generating complete debug information. | |
58 | The only thing that is absolutely required for functional code is that | |
59 | function and data *definitions* be passed to the middle-end. For | |
60 | complete debug information, function, data and type declarations | |
61 | should all be passed as well. | |
62 | ||
63 | .. index:: rest_of_decl_compilation, rest_of_type_compilation, cgraph_finalize_function | |
64 | ||
65 | In any case, the front end needs each complete top-level function or | |
66 | data declaration, and each data definition should be passed to | |
67 | ``rest_of_decl_compilation``. Each complete type definition should | |
68 | be passed to ``rest_of_type_compilation``. Each function definition | |
69 | should be passed to ``cgraph_finalize_function``. | |
70 | ||
71 | .. todo:: I know rest_of_compilation currently has all sorts of | |
72 | RTL generation semantics. I plan to move all code generation | |
73 | bits (both Tree and RTL) to compile_function. Should we hide | |
74 | cgraph from the front ends and move back to rest_of_compilation | |
75 | as the official interface? Possibly we should rename all three | |
76 | interfaces such that the names match in some meaningful way and | |
77 | that is more descriptive than "rest_of". | |
78 | ||
79 | The middle-end will, at its option, emit the function and data | |
3ed1b4ce | 80 | definitions immediately or queue them for later processing. |