| ★ wanayoo — archive 1999 http://www.gnu.org/software/gcc/projects.html | Nouvelle recherche | Portail wanayoo |
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.
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.
-foptions, and haifa doesn't help that situation.
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 optimization.
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.
A related problem: 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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
It might be possible to make better code by paying attention to the order in which to generate code for subexpressions of an expression.
Consider hoisting common code up past conditional branches or tablejumps.
Contact law@cygnus.com before working on code hoisting.
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.
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.
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.
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
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.
Pascal, Modula-2 and Ada require the implementation of functions within functions. Some of the mechanisms for this already exist.
More extensions.
struct foo {
enum { INT, DOUBLE } code;
auto union { case INT: int i; case DOUBLE: double d;} value : code;
};
(struct foo) {a, b, c} = foo();
This would call foo, which returns a structure, and then store the
several components of the structure into the variables a, b, and c.
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);
Better documentation of how GCC works and how to port it.
Here is an outline proposed by Allan Adler.