* Change the type of a variable.Sometimes a variable is declared as `int', it is assigned only oncefrom a value of type `char', and then it is used only by comparisonagainst constants.  On many machines, better code would result ifthe variable had type `char'.  If the compiler could detect thiscase, it could change the declaration of the variable and changeall the places that use it.* Order of subexpressions.It might be possible to make better code by paying attentionto the order in which to generate code for subexpressions of an expression.* More code motion.Consider hoisting common code up past conditional branches ortablejumps.* Trace scheduling.This technique is said to be able to figure out which way a jumpwill usually go, and rearrange the code to make that path thefaster one.* Distributive law.The C expression *(X + 4 * (Y + C)) compiles better on certainmachines if rewritten as *(X + 4*C + 4*Y) because of known addressingmodes.  It may be tricky to determine when, and for which machines, touse each alternative.Some work has been done on this, in combine.c.* Can optimize by changing if (x) y; else z; into z; if (x) y;if z and x do not interfere and z has no effects not undone by y.This is desirable if z is faster than jumping.* For a two-insn loop on the 68020, such as  foo:	movb	a2@+,a3@+	jne	fooit is better to insert dbeq d0,foo before the jne.d0 can be a junk register.  The challenge is to fit this intoa portable framework: when can you detect this situation andstill be able to allocate a junk register?2. Simpler porting.Right now, describing the target machine's instructions is donecleanly, but describing its addressing mode is done with severalad-hoc macro definitions.  Porting would be much easier if there werean RTL description for addressing modes like that for instructions.Tools analogous to genflags and genrecog would generate macros fromthis description.There would be one pattern in the address-description file for eachkind of addressing, and this pattern would have:  * the RTL expression for the address  * C code to verify its validity (since that may depend on    the exact data).  * C code to print the address in assembler language.  * C code to convert the address into a valid one, if it is not valid.    (This would replace LEGITIMIZE_ADDRESS).  * Register constraints for all indeterminates that appear    in the RTL expression.3. Other languages.Front ends for Pascal, Fortran, Algol, Cobol, Modula-2 and Ada aredesirable.Pascal, Modula-2 and Ada require the implementation of functionswithin functions.  Some of the mechanisms for this already exist.4. More extensions.* Label-addresses as expressions.It would be nice to have access to the addresses of labels; to be able tostore them in variables, or initialize vectors of them.Alas, `&label0' is the address of the variable named label0, which isunrelated to the label with that name.  Some other syntax is needed.Perhaps colon as a unary operator?  That is ambiguous with `?:' withthe middle operand omitted.  Perhaps ^ as a unary operator?  Perhaps`__label__ label0' could mean the value of label0?  Its type could be`void *'.  `goto *EXP' could be used to go to a value of type `void*'--no ambiguity there.Jump optimization and flow analysis must know about computed jumps,but that is not hard.  Each basic block headed by a possible target ofcomputed jumps must be considered a successor of each basic blockending in a computed jump.  Aside from this, I believe no otheroptimizer changes are needed.Next question: stack levels.  In most functions, there is no problem,but it would be a shame to make a feature that doesn't work togetherwith other features.  Here is an idea:For each label that might need stack level restoration, construct ashadow-label which will restore the stack and jump to the user-label.Then use the address of the shadow label for label0 when someone asksfor that of label0.  Jump optimization will delete all the shadow labelsif the function has no computed gotos.* Generated unique labels.  Have some way of generating distinct labelsfor use in extended asm statements.  I don't know what a good syntax wouldbe.5. Generalize the machine model.* Some new compiler features may be needed to do a good job on machineswhere static data needs to be addressed using base registers.* Some machines have two stacks in different areas of memory, one usedfor scalars and another for large objects.  The compiler does notnow have a way to understand this.6. Better documentation of how GCC works and how to port it.Here is an outline proposed by Allan Adler.I.    Overview of this documentII.   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 madeIII.   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 reasoningIV.    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 reasoningV.     Uses of the file aux-output.cVI.    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 codeVII.   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 recognizerditto for other componentsVIII. Data types used by GCC, with special reference to restrictions not       specified in the formal definition of the data typeIX.   References to the literature for the algorithms used in GCC