0. Improved efficiency.* Parse and output array initializers an element at a time, freeingstorage after each, instead of parsing the whole initializer first andthen outputting.  This would reduce memory usage for largeinitializers.1. Better optimization.* Constants in unused inline functionsIt would be nice to delay output of string constants so that stringconstants 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 refersto the constant (currently, only by an assembler symbol name)to point to the constant and cause it to be output.* More cseThe techniques for doing full global cse are described in the reddragon book, or (a different version) in Frederick Chow's thesis fromStanford.  It is likely to be slow and use a lot of memory, but itmight be worth offering as an additional option.It is probably possible to extend cse to a few very frequent caseswithout so much expense.For example, it is not very hard to handle cse through if-thenstatements with no else clauses.  Here's how to do it.  On reaching alabel, notice that the label's use-count is 1 and that the lastpreceding jump jumps conditionally to this label.  Now you know itis a simple if-then statement.  Remove from the hash tableall the expressions that were entered since that jump insnand you can continue with cse.It is probably not hard to handle cse from the end of a looparound to the beginning, and a few loops would be greatly spedup by this.* Support more general tail-recursion among different functions.This might be possible under certain circumstances, such as whenthe argument lists of the functions have the same lengths.Perhaps it could be done with a special declaration.You would need to verify in the calling function that it does notuse the addresses of any local variables and does not use setjmp.* Put short statics vars at low addresses and use short addressing mode?Useful on the 68000/68020 and perhaps on the 32000 series,provided one has a linker that works with the feature.This is said to make a 15% speedup on the 68000.* Keep global variables in registers.Here is a scheme for doing this.  A global variable, or a local variablewhose address is taken, can be kept in a register for an entire functionif it does not use non-constant memory addresses and (for globals only)does not call other functions.  If the entire function does not meetthis criterion, a loop may.The VAR_DECL for such a variable would have to have two RTL expressions:the true home in memory, and the pseudo-register used temporarily. It is necessary to emit insns to copy the memory location into thepseudo-register at the beginning of the function or loop, and perhapsback out at the end.  These insns should have REG_EQUIV notes so that,if the pseudo-register does not get a hard register, it is spilled intothe memory location which exists in any case.The easiest way to set up these insns is to modify the routineput_var_into_stack so that it does not apply to the entire function(sparing any loops which contain nothing dangerous) and to call it atthe end of the function regardless of where in the function theaddress of a local variable is taken.  It would be calledunconditionally at the end of the function for all relevant globalvariables.For debugger output, the thing to do is to invent a new binding levelaround the appropriate loop and define the variable name as a registervariable with that scope.* Live-range splitting.Currently a variable is allocated a hard register either for the fullextent of its use or not at all.  Sometimes it would be good toallocate a variable a hard register for just part of a function; forexample, through a particular loop where the variable is mostly used,or outside of a particular loop where the variable is not used.  (Thelatter is nice because it might let the variable be in a register mostof the time even though the loop needs all the registers.)It might not be very hard to do this in global-alloc.c when a variablefails to get a hard register for its entire life span.The first step is to find a loop in which the variable is live, butwhich is not the whole life span or nearly so.  It's probably best touse a loop in which the variable is heavily used.Then create a new pseudo-register to represent the variable in that loop.Substitute this for the old pseudo-register there, and insert move insnsto copy between the two at the loop entry and all exits.  (When severalsuch moves are inserted at the same place, some new feature should beadded to say that none of those registers conflict merely because ofoverlap between the new moves.  And the reload pass should reorder themso that a store precedes a load, for any given hard register.)After doing this for all the reasonable candidates, run global-allocover again.  With luck, one of the two pseudo-registers will be fitsomewhere.  It may even have a much higher priority due to its reducedlife span.There will be no room in general for the new pseudo-registers inbasic_block_live_at_start, so there will need to be a second suchmatrix exclusively for the new ones.  Various other vectors indexed byregister number will have to be made bigger, or there will have to besecondary extender vectors just for global-alloc.A simple new feature could arrange that both pseudo-registers get thesame stack slot if they both fail to get hard registers.Other compilers split live ranges when they are not connected, ortry to split off pieces `at the edge'.  I think splitting around loopswill provide more speedup.Creating a fake binding block and a new like-named variable withshorter life span and different address might succeed in describingthis technique for the debugger.* Detect dead stores into memory?A store into memory is dead if it is followed by another store intothe same location; and, in between, there is no reference to anythingthat might be that location (including no reference to a variableaddress).* Loop optimization.Strength reduction and iteration variable elimination could besmarter.  They should know how to decide which iteration variables arenot worth making explicit because they can be computed as part of anaddress calculation.  Based on this information, they should decidewhen it is desirable to eliminate one iteration variable and createanother in its place.It should be possible to compute what the value of an iterationvariable will be at the end of the loop, and eliminate the variablewithin the loop by computing that value at the loop end.When a loop has a simple increment that adds 1,instead of jumping in after the increment,decrement the loop count and jump to the increment.This allows aob insns to be used.* Using constraints on values.Many operations could be simplified based on knowledge of theminimum and maximum possible values of a register at any particular time.These limits could come from the data types in the tree, via rtl generation,or they can be deduced from operations that are performed.  For example,the result of an `and' operation one of whose operands is 7 must be inthe range 0 to 7.  Compare instructions also tell something about thepossible values of the operand, in the code beyond the test.Value constraints can be used to determine the results of a furthercomparison.  They can also indicate that certain `and' operations areredundant.  Constraints might permit a decrement and branchinstruction that checks zeroness to be used when the user hasspecified to exit if negative.* Smarter reload pass.The reload pass as currently written can reload values only into registersthat are reserved for reloading.  This means that in order to use aregister for reloading it must spill everything out of that register.It would be straightforward, though complicated, for reload1.c to keeptrack, during its scan, of which hard registers were available at eachpoint in the function, and use for reloading even registers that werefree only at the point they were needed.  This would avoid much spillingand make better code.