Return to PROJECTS CVS log

Up to [GCC 1.x] / gcc

Annotation of gcc/PROJECTS, revision 1.1

1.1     ! root        1: 1. Better optimization.
        !             2: 
        !             3: * More cse
        !             4: 
        !             5: The techniques for doing full global cse are described in the
        !             6: red dragon book.  It is likely to be slow and use a lot of memory,
        !             7: but it might be worth offering as an additional option.
        !             8: 
        !             9: It is probably possible to extend cse to a few very frequent cases
        !            10: without so much expense.
        !            11: 
        !            12: For example, it is not very hard to handle cse through if-then
        !            13: statements with no else clauses.  Here's how to do it.  On reaching a
        !            14: label, notice that the label's use-count is 1 and that the last
        !            15: preceding jump jumps conditionally to this label.  Now you know it
        !            16: is a simple if-then statement.  Remove from the hash table
        !            17: all the expressions that were entered since that jump insn
        !            18: and you can continue with cse.
        !            19: 
        !            20: It is probably not hard to handle cse from the end of a loop
        !            21: around to the beginning, and a few loops would be greatly sped
        !            22: up by this.
        !            23: 
        !            24: * Iteration variables and strength reduction.
        !            25: 
        !            26: The red dragon book describes standard techniques for these kinds
        !            27: of loop optimization.  But be careful!  These optimization techniques
        !            28: don't always make the code better.  You need to avoid performing
        !            29: the standard transformations unless they are greatly worth while.
        !            30: 
        !            31: In many common cases it is possible to deduce that an iteration
        !            32: variable is always positive during the loop.  This information
        !            33: may make it possible to use decrement-and-branch instructions
        !            34: whose branch conditions are inconvenient.  For example, the 68000
        !            35: `dbra' instruction branches if the value was not equal to zero.
        !            36: Therefore, it is not applicable to `for (i = 10; i >= 0; i--)'
        !            37: unless the compiler can know that I will never be negative
        !            38: before it is decremented.
        !            39: 
        !            40: * Special local optimizations.
        !            41: 
        !            42: The instruction combiner finds only certain classes of local optimizations.
        !            43: For example, it cannot use the 68020 instruction `cmp2' because it would
        !            44: not think to combine the instructions that would be equivalent to a `cmp2'.
        !            45: 
        !            46: In order to take advantage of such instructions, the combiner would need
        !            47: special hints as to which instructions to consider combining.  To be
        !            48: generally useful, this feature would have to be controlled somehow
        !            49: by new information in the machine description.
        !            50: 
        !            51: * Smarter reload pass.
        !            52: 
        !            53: The reload pass as currently written can reload values only into registers
        !            54: that are reserved for reloading.  This means that in order to use a
        !            55: register for reloading it must spill everything out of that register.
        !            56: 
        !            57: It would be straightforward, though complicated, for reload1.c to keep
        !            58: track, during its scan, of which hard registers were available at each
        !            59: point in the function, and use for reloading even registers that were
        !            60: free only at the point they were needed.  This would avoid much spilling
        !            61: and make better code.
        !            62: 
        !            63: * Change the type of a variable.
        !            64: 
        !            65: Sometimes a variable is declared as `int', it is assigned only once
        !            66: from a value of type `char', and then it is used only by comparison
        !            67: against constants.  On many machines, better code would result if
        !            68: the variable had type `char'.  If the compiler could detect this
        !            69: case, it could change the declaration of the variable and change
        !            70: all the places that use it.
        !            71: 
        !            72: * Order of subexpressions.
        !            73: 
        !            74: It might be possible to make better code by paying attention
        !            75: to the order in which to generate code for subexpressions of an expression.
        !            76: 
        !            77: * Better code for switch statements.
        !            78: 
        !            79: If a switch statement has only a few cases, a sequence of conditional
        !            80: branches is generated for it, rather than a jump table.  It would
        !            81: be better to output a binary tree of branches.
        !            82: 
        !            83: * Distributive law.
        !            84: 
        !            85: *(X + 4 * (Y + C)) compiles better as *(X + 4*C + 4*Y)
        !            86: on some machines because of known addressing modes.
        !            87: It may be tricky to determine when, and for which machines,
        !            88: to use each alternative.
        !            89: 
        !            90: 2. Simpler porting.
        !            91: 
        !            92: Right now, describing the target machine's instructions is done
        !            93: cleanly, but describing its addressing mode is done with several
        !            94: ad-hoc macro definitions.  Porting would be much easier if there were
        !            95: an RTL description for addressing modes like that for instructions.
        !            96: Tools analogous to genflags and genrecog would generate macros from
        !            97: this description.
        !            98: 
        !            99: There would be one pattern in the address-description file for each
        !           100: kind of addressing, and this pattern would have:
        !           101: 
        !           102:   * the RTL expression for the address
        !           103:   * C code to verify its validity (since that may depend on
        !           104:     the exact data).
        !           105:   * C code to print the address in assembler language.
        !           106:   * C code to convert the address into a valid one, if it is not valid.
        !           107:     (This would replace LEGITIMIZE_ADDRESS).
        !           108:   * Register constraints for all indeterminates that appear
        !           109:     in the RTL expression.
        !           110: 
        !           111: 3. Other languages.
        !           112: 
        !           113: Front ends for Pascal, Fortran, Algol, Cobol and Ada are desirable.
        !           114: 
        !           115: Pascal requires the implementation of functions within functions.
        !           116: Some of the mechanisms for this already exist.
        !           117: 
        !           118: 4. Generalize the machine model.
        !           119: 
        !           120: 4.A. Parameters in registers.
        !           121: 
        !           122: One some machines, conventions are that some parameters are passed
        !           123: in general registers.  The compiler currently cannot handle this.
        !           124: 
        !           125: This requires changes in the code in expr.c for function calls.
        !           126: For function entry, changes are required in stmt.c, and in
        !           127: layout_parms, and perhaps also in final and in register allocation,
        !           128: but the last should be minor.
        !           129: 
        !           130: Where stmt.c now copies the stack slot into a pseudo register,
        !           131: instead copy the special argument register into a pseudo register.
        !           132: Use the pseudo register throughout the body of the function to
        !           133: represent the parameter.  That way, parameters can still be spilled
        !           134: to the stack.
        !           135: 
        !           136: 4.B. Jump-execute-next.
        !           137: 
        !           138: Many recent machines have jumps which execute the following instruction
        !           139: before the instruction jumped to.  To take advantage of this capability
        !           140: requires a new compiler pass that would reorder instructions when possible.
        !           141: After reload is a good place for it.
        !           142: 
        !           143: 5. Add a profiling feature like Berkeley's -pg,
        !           144: or other debugging and measurement features.
        !           145: 

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.