--- gcc/PROJECTS 2018/04/24 16:49:02 1.1.1.3 +++ gcc/PROJECTS 2018/04/24 16:51:24 1.1.1.5 @@ -1,5 +1,15 @@ 1. Better optimization. +* Constants in unused inline functions + +It would be nice to delay output of string constants so that string +constants mentioned in unused inline functions are never generated. +Perhaps this would also take care of string constants in dead code. + +The difficulty is in finding a clean way for the RTL which refers +to the constant (currently, only by an assembler symbol name) +to point to the constant and cause it to be output. + * More cse The techniques for doing full global cse are described in the @@ -39,9 +49,9 @@ This brings to mind Hayes' changes for S * Detect dead stores into memory? A store into memory is dead if it is followed by another store into -the same location; and, in between, there is no reference to -that anything that might be that location (including no reference -to a variable address). +the same location; and, in between, there is no reference to anything +that might be that location (including no reference to a variable +address). * Loop optimization. @@ -49,7 +59,7 @@ Strength reduction and iteration variabl smarter. They should know how to decide which iteration variables are not worth making explicit because they can be computed as part of an address calculation. Based on this information, they should decide -when it is desirable to eliminate one iteration iable and create +when it is desirable to eliminate one iteration variable and create another in its place. It should be possible to compute what the value of an iteration @@ -190,10 +200,10 @@ within functions. Some of the mechanism 4. Generalize the machine model. -Some new compiler features may be needed to do a good job on machines +* Some new compiler features may be needed to do a good job on machines where static data needs to be addressed using base registers. -Some machines have two stacks in different areas of memory, one used +* Some machines have two stacks in different areas of memory, one used for scalars and another for large objects. The compiler does not now have a way to understand this. @@ -265,3 +275,80 @@ files' contents. This would use a new o The second step is to divide the output into strings, some keyed and some unconditional. This division is done without changing the order of the text being divided up. + +JNC@lcs.mit.edu has some ideas on this subject also. + +6. Other possibly nice features. + +* cpp could have a #provide directive. +#provide would have the same syntax as #include, +and it would nullify any future #include directive +with the same argument. Thus, the file foo.h +could contain #provide to prevent itself from +being included twice. + +This is much cleaner than the alternative sometimes implemented, +which is to require the user to use something other than #include +in order to ensure inclusion only once. + +7. Better documentation of how GCC works and how to port it. + +Here is an outline proposed by Allan Adler. + +I. Overview of this document +II. The machines on which GCC is implemented + A. Prose description of those characteristics of target machines and + their operating systems which are pertinent to the implementation + of GCC. + i. target machine characteristics + ii. comparison of this system of machine characteristics with + other systems of machine specification currently in use + B. Tables of the characteristics of the target machines on which + GCC is implemented. + C. A priori restrictions on the values of characteristics of target + machines, with special reference to those parts of the source code + which entail those restrictions + i. restrictions on individual characteristics + ii. restrictions involving relations between various characteristics + D. The use of GCC as a cross-compiler + i. cross-compilation to existing machines + ii. cross-compilation to non-existent machines + E. Assumptions which are made regarding the target machine + i. assumptions regarding the architecture of the target machine + ii. assumptions regarding the operating system of the target machine + iii. assumptions regarding software resident on the target machine + iv. where in the source code these assumptions are in effect made +III. A systematic approach to writing the files tm.h and xm.h + A. Macros which require special care or skill + B. Examples, with special reference to the underlying reasoning +IV. A systematic approach to writing the machine description file md + A. Minimal viable sets of insn descriptions + B. Examples, with special reference to the underlying reasoning +V. Uses of the file aux-output.c +VI. Specification of what constitutes correct performance of an + implementation of GCC + A. The components of GCC + B. The itinerary of a C program through GCC + C. A system of benchmark programs + D. What your RTL and assembler should look like with these benchmarks + E. Fine tuning for speed and size of compiled code +VII. A systematic procedure for debugging an implementation of GCC + A. Use of GDB + i. the macros in the file .gdbinit for GCC + ii. obstacles to the use of GDB + a. functions implemented as macros can't be called in GDB + B. Debugging without GDB + i. How to turn off the normal operation of GCC and access specific + parts of GCC + C. Debugging tools + D. Debugging the parser + i. how machine macros and insn definitions affect the parser + E. Debugging the recognizer + i. how machine macros and insn definitions affect the recognizer + +ditto for other components + +VIII. Data types used by GCC, with special reference to restrictions not + specified in the formal definition of the data type +IX. References to the literature for the algorithms used in GCC +