GCC Projects

These are some potential future projects for GCC. Most of them have to do with the optimizer. Some are old ideas which might not help very much anymore, but who knows?

There is a separate page for Bounds Checking with Bounded Pointers.

There is a separate project list for the C preprocessor.

We also have a page detailing optimizer inadequacies, if you'd prefer to think about it in terms of problems instead of features.

Changes to support C99 standard

The new version of the C standard (ISO/IEC 9899:1999) requires a number of library changes; these have to be provided by the C library, and not by gcc. In addition, there are also changes to the language proper, and some compiler support is needed for the new library features. An overview of the C99 implementation status is available.

Haifa scheduler

(haifa-sched.c, loop.[ch], unroll.c, genattrtab.c): (contact law@cygnus.com before starting any serious haifa work)

Improvements to global cse and partial redundancy elimination:

The current implementation of global cse uses partial redundancy elimination via lazy code motion (lcm).

lcm also provides the underlying framework for several additional optimizations such as shrink wrapping, spill code motion, dead store elimination, and generic load/store motion (all the other examples are subcases of load/store motion).

It can probably also be used to improve the reg-stack pass of the compiler.

Contact law@cygnus.com if you're interested in working on lazy code motion.

Better builtin string functions

GNU libc includes some macros to optimize calls to some string functions with constant arguments. These macros tend to cause huge blowup in the size of preprocessed source if nested; for example, each nested call to strcpy expands the source 20-fold, with four nested calls having an expansion ten megabytes in size. GCC then consumes a huge amount of memory compiling such expressions. Many of the optimizations to ISO C string functions could be implemented in GCC and then disabled in glibc, with benefits to other systems as well, and the potential to use information GCC has about alignment.

All the string functions act as if they access individual characters, so care may need to be taken that no -fstrict-aliasing problems occur when internal uses of other types are generated. Also, the arguments to the string function must be evaluated exactly once each (if they have any side effects), even though the call to the string function might be optimized away.

Care must be taken that any optimizations in GCC are standards-conforming in terms of not possibly accessing beyond the arrays involved (possibly within a function call created in the optimization); whereas the glibc macros know the glibc implementation and how much memory it might access, GCC optimizations can't. When -fcheck-memory-usage is used, calls to the checking functions from Checker may need to be emitted; see the existing builtin string functions in GCC for examples.

There are some further optimizations in glibc not covered here, that either optimize calls to non-ISO C functions or call glibc internal functions in the expansion of the macro.

glibc also has inline assembler versions of various string functions; GCC has some, but not necessarily the same ones on the same architectures.

Many of these optimizations should not be applied if -Os is specified.

Format (printf, scanf and strftime) checking:

Contact jsm28@cam.ac.uk before doing any substantial format checking work.


The old PROJECTS file

Stuff I know has been done has been deleted. Stuff in progress has a contact name associated with it.

Better optimization.

  1. Putting constants in special sections.

    If a function has been placed in a special section via attributes, we may want to put its static data and string constants in a special section too. But which one? (Being able to specify a section for string constants would be useful for the Linux kernel.)

  2. Optimize a sequence of if statements whose conditions are exclusive.

    It is possible to optimize

    if (x == 1) ...;
    if (x == 2) ...;
    if (x == 3) ...;
    
    into
    if (x == 1) ...;
    else if (x == 2) ...;
    else if (x == 3) ...;
    
    provided that x is not altered by the contents of the if statements.

    It's not certain whether this is worth doing. Perhaps programmers nearly always write the else's themselves, leaving few opportunities to improve anything.

  3. Un-cse.

    Perhaps we should have an un-cse step right after cse, which tries to replace a reg with its value if the value can be substituted for the reg everywhere, if that looks like an improvement. Which is if the reg is used only a few times. Use rtx_cost to determine if the change is really an improvement.

  4. Clean up how cse works.

    The scheme is that each value has just one hash entry. The first_same_value and next_same_value chains are no longer needed.

    For arithmetic, each hash table elt has the following slots:

    So, if we want to enter (plus:SI (reg:SI 30) (const_int 104)), we first enter (const_int 104) and find the entry that (reg:SI 30) now points to. Then we put these elts into operands 0 and 1 of a new elt. We put PLUS and SI into the new elt.

    Registers and mem refs would never be entered into the table as such. However, the values they contain would be entered. There would be a table indexed by regno which points at the hash entry for the value in that reg.

    The hash entry index now plays the role of a qty number. We still need qty_first_reg, reg_next_eqv, etc. to record which regs share a particular qty.

    When a reg is used whose contents are unknown, we need to create a hash table entry whose contents say "unknown", as a place holder for whatever the reg contains. If that reg is added to something, then the hash entry for the sum will refer to the "unknown" entry. Use UNKNOWN for the rtx code in this entry. This replaces make_new_qty.

    For a constant, a unique hash entry would be made based on the value of the constant.

    What about MEM? Each time a memory address is referenced, we need a qty (a hash table elt) to represent what is in it. (Just as for a register.) If this isn't known, create one, just as for a reg whose contents are unknown.

    We need a way to find all mem refs that still contain a certain value. Do this with a chain of hash elts (for memory addresses) that point to locations that hold the value. The hash elt for the value itself should point to the start of the chain. It would be good for the hash elt for an address to point to the hash elt for the contents of that address (but this ptr can be null if the contents have never been entered).

    With this data structure, nothing need ever be invalidated except the lists of which regs or mems hold a particular value. It is easy to see if there is a reg or mem that is equiv to a particular value. If the value is constant, it is always explicitly constant.

  5. Support more general tail-recursion among different functions.

    This might be possible under certain circumstances, such as when the 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 not use the addresses of any local variables (?) and does not use setjmp.

    -foptimize-sibling-calls does at least some of this.

  6. 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.

  7. Keep global variables in registers.

    Here is a scheme for doing this. A global variable, or a local variable whose address is taken, can be kept in a register for an entire function if it does not use non-constant memory addresses and (for globals only) does not call other functions. If the entire function does not meet this 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 the pseudo-register at the beginning of the function or loop, and perhaps back 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 into the memory location which exists in any case.

    The easiest way to set up these insns is to modify the routine put_var_into_stack so that it does not apply to the entire function (sparing any loops which contain nothing dangerous) and to call it at the end of the function regardless of where in the function the address of a local variable is taken. It would be called unconditionally at the end of the function for all relevant global variables.

    For debugger output, the thing to do is to invent a new binding level around the appropriate loop and define the variable name as a register variable with that scope.

  8. Live-range splitting.

    Currently a variable is allocated a hard register either for the full extent of its use or not at all. Sometimes it would be good to allocate a variable a hard register for just part of a function; for example, through a particular loop where the variable is mostly used, or outside of a particular loop where the variable is not used. (The latter is nice because it might let the variable be in a register most of the time even though the loop needs all the registers.) Contact meissner@cygnus.com before starting any work on live range splitting.

  9. 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 anything that might be that location (including no reference to a variable address).

    This can be modeled as a partial redundancy elimination/lazy code motion problem. Contact law@cygnus.com before working on dead store elimination optimizations.

  10. Loop optimization.

    Strength reduction and iteration variable elimination could be 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 variable and create another in its place.

    It should be possible to compute what the value of an iteration variable will be at the end of the loop, and eliminate the variable within 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.

  11. Using constraints on values.

    Many operations could be simplified based on knowledge of the minimum 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 in the range 0 to 7. Compare instructions also tell something about the possible values of the operand, in the code beyond the test.

    Value constraints can be used to determine the results of a further comparison. They can also indicate that certain and operations are redundant. Constraints might permit a decrement and branch instruction that checks zeroness to be used when the user has specified to exit if negative.

    John Wehle (john@feith.com) implemented a value range propagation pass which isn't yet in GCC.

  12. Change the type of a variable.

    Sometimes a variable is declared as int, it is assigned only once from a value of type char, and then it is used only by comparison against constants. On many machines, better code would result if the variable had type char. If the compiler could detect this case, it could change the declaration of the variable and change all the places that use it.

  13. Better handling for very sparse switches.

    There may be cases where it would be better to compile a switch statement to use a fixed hash table rather than the current combination of jump tables and binary search.

  14. Order of subexpressions.

    It might be possible to make better code by paying attention to the order in which to generate code for subexpressions of an expression.

  15. More code motion.

    Consider hoisting common code up past conditional branches or tablejumps.

    Contact law@cygnus.com before working on code hoisting.

  16. Trace scheduling.

    This technique is said to be able to figure out which way a jump will usually go, and rearrange the code to make that path the faster one.

  17. Distributive law.

    The C expression *(X + 4 * (Y + C)) compiles better on certain machines if rewritten as *(X + 4*C + 4*Y) because of known addressing modes. It may be tricky to determine when, and for which machines, to use each alternative.

    Some work has been done on this, in combine.c.

  18. 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.
  19. For a two-insn loop on the 68020, such as
    foo:	movb	a2@+,a3@+
    	jne	foo
    
    it is better to insert dbeq d0,foo before the jne. d0 can be a junk register. The challenge is to fit this into a portable framework: when can you detect this situation and still be able to allocate a junk register?

Simpler porting

Right now, describing the target machine's instructions is done cleanly, but describing its addressing mode is done with several ad-hoc macro definitions. Porting would be much easier if there were an RTL description for addressing modes like that for instructions. Tools analogous to genflags and genrecog would generate macros from this description.

There would be one pattern in the address-description file for each kind of addressing, and this pattern would have:

Other languages

We currently have front ends for C, C++, Objective C, CHILL, Fortran, and Java. Pascal and Ada front ends exist but have not yet been integrated.

Cobol and Modula-2 front ends might be useful, and are being worked on.

Pascal, Modula-2 and Ada require the implementation of functions within functions. Some of the mechanisms for this already exist.

More extensions

Generalize the machine model

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 for scalars and another for large objects. The compiler does not now have a way to understand this.

The scheduler does not do very well on recent RISC machines. Haifa helps but not enough.

More warnings

Warn about statements that are undefined because the order of evaluation of increment operators makes a big difference. Here is an example:

*foo++ = hack (*foo);

-Wsequence-point does some of this, but not that particular case.

Better documentation of how GCC works and how to port it

Here is an outline proposed by Allan Adler.

  1. Overview of this document
  2. The machines on which GCC is implemented
    1. Prose description of those characteristics of target machines and their operating systems which are pertinent to the implementation of GCC.
      1. target machine characteristics
      2. comparison of this system of machine characteristics with other systems of machine specification currently in use
    2. Tables of the characteristics of the target machines on which GCC is implemented.
    3. 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
      1. restrictions on individual characteristics
      2. restrictions involving relations between various characteristics
    4. The use of GCC as a cross-compiler
      1. cross-compilation to existing machines
      2. cross-compilation to non-existent machines
    5. Assumptions which are made regarding the target machine
      1. assumptions regarding the architecture of the target machine
      2. assumptions regarding the operating system of the target machine
      3. assumptions regarding software resident on the target machine
      4. where in the source code these assumptions are in effect made.
  3. A systematic approach to writing the files tm.h and xm.h
    1. Macros which require special care or skill
    2. Examples, with special reference to the underlying reasoning
  4. A systematic approach to writing the machine description file
    1. Minimal viable sets of insn descriptions
    2. Examples, with special reference to the underlying reasoning
  5. Uses of the file aux-output.c
  6. Specification of what constitutes correct performance of an implementation of GCC
    1. The components of GCC
    2. The itinerary of a C program through GCC
    3. A system of benchmark programs
    4. What your RTL and assembler should look like with these benchmarks
    5. Fine tuning for speed and size of compiled code
  7. A systematic procedure for debugging an implementation of GCC
    1. Use of GDB
      1. the macros in the file .gdbinit for GCC
      2. obstacles to the use of GDB
        1. functions implemented as macros can't be called in GDB
    2. Debugging without GDB
      1. How to turn off the normal operation of GCC and access specific parts of GCC
    3. Debugging tools
    4. Debugging the parser
      1. how machine macros and insn definitions affect the parser
    5. Debugging the recognizer
      1. how machine macros and insn definitions affect the recognizer
    6. ... ditto for other components ...
  8. Data types used by GCC, with special reference to restrictions not specified in the formal definition of the data type
  9. References to the literature for the algorithms used in GCC

The old PROBLEMS file

The following used to be in a file PROBLEMS in the GCC distribution. Probably much of it is no longer relevant as of GCC 3.0 (the file hadn't changed since GCC 2.0), but some might be. Someone should go through it, identifying what is and isn't relevant, adding anything applicable to current GCC (and describing a bug) to GNATS and sending patches to gcc-patches to remove from the list entries that no longer apply or have been entered in GNATS.

  1. When find_reloads is used to count number of spills needed it does not take into account the fact that a reload may turn out to be a dummy.

    I'm not sure this really happens any more. Doesn't it find all the dummies on both passes?

  2.         movl a3@,a0
            movl a3@(16),a1
            clrb a0@(a1:l)
    

    is generated and may be worse than

            movl a3@,a0
            addl a3@(16),a0
            clrb a0@
    

    If ordering of operands is improved, many more such cases will be generated from typical array accesses.

  3. Hack expand_mult so that if there is no same-modes multiply it will use a widening multiply and then truncate rather than calling the library.
  4. Hack expanding of division to notice cases for long -> short division.
  5. Represent divide insns as (DIV:SI ...) followed by a separate lowpart extract. Represent remainder insns as DIV:SI followed by a separate highpart extract. Then cse can work on the DIV:SI part. Problem is, this may not be desirable on machines where computing the quotient alone does not necessarily give a remainder--such as the 68020 for long operands.
  6. Reloading can look at how reload_contents got set up. If it was copied from a register, just reload from that register. Otherwise, perhaps can change the previous insn to move the data via the reload reg, thus avoiding one memory ref.
  7. Potential problem in cc_status.value2, if it ever activates itself after a two-address subtraction (which currently cannot happen). It is supposed to compare the current value of the destination but eliminating it would use the results of the subtraction, equivalent to comparing the previous value of the destination.
  8. Should loops that neither start nor end with a break be rearranged to end with the last break?
  9. Define the floating point converting arithmetic instructions for the 68881.
  10. Combine loop opt with cse opt in one pass. Do cse on each loop, then loop opt on that loop, and go from innermost loops outward. Make loop invariants available for cse at end of loop.
  11. pea can force a value to be reloaded into an areg which can make it worse than separate adding and pushing. This can only happen for adding something within addql range and it only loses if the qty becomes dead at that point so it can be added to with no copying.
  12. If a pseudo doesn't get a hard reg everywhere, can it get one during a loop?
  13. Can do SImode bitfield insns without reloading, but must alter the operands in special ways.
  14. final could check loop-entry branches to see if they screw up deletion of a test instruction. If they do, can put another test instruction before the branch and make it conditional and redirect it.
  15. Aliasing may be impossible if data types of refs differ and data type of containing objects also differ. (But check this wrt unions.) This may now be covered by -fstrict-aliasing.
  16. Can speed up flow analysis by making a table saying which register is set and which registers are used by each instruction that only sets one register and only uses two. This way avoid the tree walk for such instructions (most instructions).
  17. It is desirable to avoid converting INDEX to SImode if a narrower mode suffices, as HImode does on the 68000. How can this be done?
  18. Possible special combination pattern: If the two operands to a comparison die there and both come from insns that are identical except for replacing one operand with the other, throw away those insns. Ok if insns being discarded are known 1 to 1. An andl #1 after a seq is 1 to 1, but how should compiler know that?
  19. Can convert float to unsigned int by subtracting a constant, converting to signed int, and changing the sign bit.
  20. Any number of slow zero-extensions in one loop, that have their clr insns moved out of the loop, can share one register if their original life spans are disjoint. But it may be hard to be sure of this since the life span data that regscan produces may be hard to interpret validly or may be incorrect after cse.
  21. In cse, when a bfext insn refers to a register, if the field corresponds to a halfword or a byte and the register is equivalent to a memory location, it would be possible to detect this and replace it with a simple memory reference.
  22. Insns that store two values cannot be moved out of loops. The code in scan_loop doesn't even try to deal with them.
  23. When insn-output.c turns a bit-test into a sign-test, it should see whether the cc is already set up with that sign.
  24. When a conditional expression is used as a function arg, it would be faster (and in some cases shorter) to push each alternative rather than compute in a register and push that. This would require being able to specify "push this" as a target for expand_expr.
  25. On the 386, bad code results from foo (bar ()) when bar returns a double, because the pseudo used fails to get preferenced into an fp reg because of the distinction between regs 8 and 9.