1 | 0. Improved efficiency. |
---|
2 | |
---|
3 | * Parse and output array initializers an element at a time, freeing |
---|
4 | storage after each, instead of parsing the whole initializer first and |
---|
5 | then outputting. This would reduce memory usage for large |
---|
6 | initializers. |
---|
7 | |
---|
8 | * See if the techniques describe in Oct 1991 SIGPLAN Notices |
---|
9 | (Frazer and Hanson) are applicable to GCC. |
---|
10 | |
---|
11 | 1. Better optimization. |
---|
12 | |
---|
13 | * Constants in unused inline functions |
---|
14 | |
---|
15 | It would be nice to delay output of string constants so that string |
---|
16 | constants mentioned in unused inline functions are never generated. |
---|
17 | Perhaps this would also take care of string constants in dead code. |
---|
18 | |
---|
19 | The difficulty is in finding a clean way for the RTL which refers |
---|
20 | to the constant (currently, only by an assembler symbol name) |
---|
21 | to point to the constant and cause it to be output. |
---|
22 | |
---|
23 | * More cse |
---|
24 | |
---|
25 | The techniques for doing full global cse are described in the red |
---|
26 | dragon book, or (a different version) in Frederick Chow's thesis from |
---|
27 | Stanford. It is likely to be slow and use a lot of memory, but it |
---|
28 | might be worth offering as an additional option. |
---|
29 | |
---|
30 | It is probably possible to extend cse to a few very frequent cases |
---|
31 | without so much expense. |
---|
32 | |
---|
33 | For example, it is not very hard to handle cse through if-then |
---|
34 | statements with no else clauses. Here's how to do it. On reaching a |
---|
35 | label, notice that the label's use-count is 1 and that the last |
---|
36 | preceding jump jumps conditionally to this label. Now you know it |
---|
37 | is a simple if-then statement. Remove from the hash table |
---|
38 | all the expressions that were entered since that jump insn |
---|
39 | and you can continue with cse. |
---|
40 | |
---|
41 | It is probably not hard to handle cse from the end of a loop |
---|
42 | around to the beginning, and a few loops would be greatly sped |
---|
43 | up by this. |
---|
44 | |
---|
45 | * Optimize a sequence of if statements whose conditions are exclusive. |
---|
46 | |
---|
47 | It is possible to optimize |
---|
48 | |
---|
49 | if (x == 1) ...; |
---|
50 | if (x == 2) ...; |
---|
51 | if (x == 3) ...; |
---|
52 | |
---|
53 | into |
---|
54 | |
---|
55 | if (x == 1) ...; |
---|
56 | else if (x == 2) ...; |
---|
57 | else if (x == 3) ...; |
---|
58 | |
---|
59 | provided that x is not altered by the contents of the if statements. |
---|
60 | |
---|
61 | It's not certain whether this is worth doing. Perhaps programmers |
---|
62 | nearly always write the else's themselves, leaving few opportunities |
---|
63 | to improve anything. |
---|
64 | |
---|
65 | * Un-cse. |
---|
66 | |
---|
67 | Perhaps we should have an un-cse step right after cse, which tries to |
---|
68 | replace a reg with its value if the value can be substituted for the |
---|
69 | reg everywhere, if that looks like an improvement. Which is if the |
---|
70 | reg is used only a few times. Use rtx_cost to determine if the |
---|
71 | change is really an improvement. |
---|
72 | |
---|
73 | * Clean up how cse works. |
---|
74 | |
---|
75 | The scheme is that each value has just one hash entry. The |
---|
76 | first_same_value and next_same_value chains are no longer needed. |
---|
77 | |
---|
78 | For arithmetic, each hash table elt has the following slots: |
---|
79 | |
---|
80 | * Operation. This is an rtx code. |
---|
81 | * Mode. |
---|
82 | * Operands 0, 1 and 2. These point to other hash table elements. |
---|
83 | |
---|
84 | So, if we want to enter (PLUS:SI (REG:SI 30) (CONST_INT 104)), we |
---|
85 | first enter (CONST_INT 104) and find the entry that (REG:SI 30) now |
---|
86 | points to. Then we put these elts into operands 0 and 1 of a new elt. |
---|
87 | We put PLUS and SI into the new elt. |
---|
88 | |
---|
89 | Registers and mem refs would never be entered into the table as such. |
---|
90 | However, the values they contain would be entered. There would be a |
---|
91 | table indexed by regno which points at the hash entry for the value in |
---|
92 | that reg. |
---|
93 | |
---|
94 | The hash entry index now plays the role of a qty number. |
---|
95 | We still need qty_first_reg, reg_next_eqv, etc. to record which regs |
---|
96 | share a particular qty. |
---|
97 | |
---|
98 | When a reg is used whose contents are unknown, we need to create a |
---|
99 | hash table entry whose contents say "unknown", as a place holder for |
---|
100 | whatever the reg contains. If that reg is added to something, then |
---|
101 | the hash entry for the sum will refer to the "unknown" entry. Use |
---|
102 | UNKNOWN for the rtx code in this entry. This replaces make_new_qty. |
---|
103 | |
---|
104 | For a constant, a unique hash entry would be made based on the |
---|
105 | value of the constant. |
---|
106 | |
---|
107 | What about MEM? Each time a memory address is referenced, we need a |
---|
108 | qty (a hash table elt) to represent what is in it. (Just as for a |
---|
109 | register.) If this isn't known, create one, just as for a reg whose |
---|
110 | contents are unknown. |
---|
111 | |
---|
112 | We need a way to find all mem refs that still contain a certain value. |
---|
113 | Do this with a chain of hash elts (for memory addresses) that point to |
---|
114 | locations that hold the value. The hash elt for the value itself should |
---|
115 | point to the start of the chain. It would be good for the hash elt |
---|
116 | for an address to point to the hash elt for the contents of that address |
---|
117 | (but this ptr can be null if the contents have never been entered). |
---|
118 | |
---|
119 | With this data structure, nothing need ever be invalidated except |
---|
120 | the lists of which regs or mems hold a particular value. It is easy |
---|
121 | to see if there is a reg or mem that is equiv to a particular value. |
---|
122 | If the value is constant, it is always explicitly constant. |
---|
123 | |
---|
124 | * Support more general tail-recursion among different functions. |
---|
125 | |
---|
126 | This might be possible under certain circumstances, such as when |
---|
127 | the argument lists of the functions have the same lengths. |
---|
128 | Perhaps it could be done with a special declaration. |
---|
129 | |
---|
130 | You would need to verify in the calling function that it does not |
---|
131 | use the addresses of any local variables and does not use setjmp. |
---|
132 | |
---|
133 | * Put short statics vars at low addresses and use short addressing mode? |
---|
134 | |
---|
135 | Useful on the 68000/68020 and perhaps on the 32000 series, |
---|
136 | provided one has a linker that works with the feature. |
---|
137 | This is said to make a 15% speedup on the 68000. |
---|
138 | |
---|
139 | * Keep global variables in registers. |
---|
140 | |
---|
141 | Here is a scheme for doing this. A global variable, or a local variable |
---|
142 | whose address is taken, can be kept in a register for an entire function |
---|
143 | if it does not use non-constant memory addresses and (for globals only) |
---|
144 | does not call other functions. If the entire function does not meet |
---|
145 | this criterion, a loop may. |
---|
146 | |
---|
147 | The VAR_DECL for such a variable would have to have two RTL expressions: |
---|
148 | the true home in memory, and the pseudo-register used temporarily. |
---|
149 | It is necessary to emit insns to copy the memory location into the |
---|
150 | pseudo-register at the beginning of the function or loop, and perhaps |
---|
151 | back out at the end. These insns should have REG_EQUIV notes so that, |
---|
152 | if the pseudo-register does not get a hard register, it is spilled into |
---|
153 | the memory location which exists in any case. |
---|
154 | |
---|
155 | The easiest way to set up these insns is to modify the routine |
---|
156 | put_var_into_stack so that it does not apply to the entire function |
---|
157 | (sparing any loops which contain nothing dangerous) and to call it at |
---|
158 | the end of the function regardless of where in the function the |
---|
159 | address of a local variable is taken. It would be called |
---|
160 | unconditionally at the end of the function for all relevant global |
---|
161 | variables. |
---|
162 | |
---|
163 | For debugger output, the thing to do is to invent a new binding level |
---|
164 | around the appropriate loop and define the variable name as a register |
---|
165 | variable with that scope. |
---|
166 | |
---|
167 | * Live-range splitting. |
---|
168 | |
---|
169 | Currently a variable is allocated a hard register either for the full |
---|
170 | extent of its use or not at all. Sometimes it would be good to |
---|
171 | allocate a variable a hard register for just part of a function; for |
---|
172 | example, through a particular loop where the variable is mostly used, |
---|
173 | or outside of a particular loop where the variable is not used. (The |
---|
174 | latter is nice because it might let the variable be in a register most |
---|
175 | of the time even though the loop needs all the registers.) |
---|
176 | |
---|
177 | It might not be very hard to do this in global.c when a variable |
---|
178 | fails to get a hard register for its entire life span. |
---|
179 | |
---|
180 | The first step is to find a loop in which the variable is live, but |
---|
181 | which is not the whole life span or nearly so. It's probably best to |
---|
182 | use a loop in which the variable is heavily used. |
---|
183 | |
---|
184 | Then create a new pseudo-register to represent the variable in that loop. |
---|
185 | Substitute this for the old pseudo-register there, and insert move insns |
---|
186 | to copy between the two at the loop entry and all exits. (When several |
---|
187 | such moves are inserted at the same place, some new feature should be |
---|
188 | added to say that none of those registers conflict merely because of |
---|
189 | overlap between the new moves. And the reload pass should reorder them |
---|
190 | so that a store precedes a load, for any given hard register.) |
---|
191 | |
---|
192 | After doing this for all the reasonable candidates, run global-alloc |
---|
193 | over again. With luck, one of the two pseudo-registers will be fit |
---|
194 | somewhere. It may even have a much higher priority due to its reduced |
---|
195 | life span. |
---|
196 | |
---|
197 | There will be no room in general for the new pseudo-registers in |
---|
198 | basic_block_live_at_start, so there will need to be a second such |
---|
199 | matrix exclusively for the new ones. Various other vectors indexed by |
---|
200 | register number will have to be made bigger, or there will have to be |
---|
201 | secondary extender vectors just for global-alloc. |
---|
202 | |
---|
203 | A simple new feature could arrange that both pseudo-registers get the |
---|
204 | same stack slot if they both fail to get hard registers. |
---|
205 | |
---|
206 | Other compilers split live ranges when they are not connected, or |
---|
207 | try to split off pieces `at the edge'. I think splitting around loops |
---|
208 | will provide more speedup. |
---|
209 | |
---|
210 | Creating a fake binding block and a new like-named variable with |
---|
211 | shorter life span and different address might succeed in describing |
---|
212 | this technique for the debugger. |
---|
213 | |
---|
214 | * Detect dead stores into memory? |
---|
215 | |
---|
216 | A store into memory is dead if it is followed by another store into |
---|
217 | the same location; and, in between, there is no reference to anything |
---|
218 | that might be that location (including no reference to a variable |
---|
219 | address). |
---|
220 | |
---|
221 | * Loop optimization. |
---|
222 | |
---|
223 | Strength reduction and iteration variable elimination could be |
---|
224 | smarter. They should know how to decide which iteration variables are |
---|
225 | not worth making explicit because they can be computed as part of an |
---|
226 | address calculation. Based on this information, they should decide |
---|
227 | when it is desirable to eliminate one iteration variable and create |
---|
228 | another in its place. |
---|
229 | |
---|
230 | It should be possible to compute what the value of an iteration |
---|
231 | variable will be at the end of the loop, and eliminate the variable |
---|
232 | within the loop by computing that value at the loop end. |
---|
233 | |
---|
234 | When a loop has a simple increment that adds 1, |
---|
235 | instead of jumping in after the increment, |
---|
236 | decrement the loop count and jump to the increment. |
---|
237 | This allows aob insns to be used. |
---|
238 | |
---|
239 | * Using constraints on values. |
---|
240 | |
---|
241 | Many operations could be simplified based on knowledge of the |
---|
242 | minimum and maximum possible values of a register at any particular time. |
---|
243 | These limits could come from the data types in the tree, via rtl generation, |
---|
244 | or they can be deduced from operations that are performed. For example, |
---|
245 | the result of an `and' operation one of whose operands is 7 must be in |
---|
246 | the range 0 to 7. Compare instructions also tell something about the |
---|
247 | possible values of the operand, in the code beyond the test. |
---|
248 | |
---|
249 | Value constraints can be used to determine the results of a further |
---|
250 | comparison. They can also indicate that certain `and' operations are |
---|
251 | redundant. Constraints might permit a decrement and branch |
---|
252 | instruction that checks zeroness to be used when the user has |
---|
253 | specified to exit if negative. |
---|
254 | |
---|
255 | * Smarter reload pass. |
---|
256 | |
---|
257 | The reload pass as currently written can reload values only into registers |
---|
258 | that are reserved for reloading. This means that in order to use a |
---|
259 | register for reloading it must spill everything out of that register. |
---|
260 | |
---|
261 | It would be straightforward, though complicated, for reload1.c to keep |
---|
262 | track, during its scan, of which hard registers were available at each |
---|
263 | point in the function, and use for reloading even registers that were |
---|
264 | free only at the point they were needed. This would avoid much spilling |
---|
265 | and make better code. |
---|
266 | |
---|
267 | * Change the type of a variable. |
---|
268 | |
---|
269 | Sometimes a variable is declared as `int', it is assigned only once |
---|
270 | from a value of type `char', and then it is used only by comparison |
---|
271 | against constants. On many machines, better code would result if |
---|
272 | the variable had type `char'. If the compiler could detect this |
---|
273 | case, it could change the declaration of the variable and change |
---|
274 | all the places that use it. |
---|
275 | |
---|
276 | * Better handling for very sparse switches. |
---|
277 | |
---|
278 | There may be cases where it would be better to compile a switch |
---|
279 | statement to use a fixed hash table rather than the current |
---|
280 | combination of jump tables and binary search. |
---|
281 | |
---|
282 | * Order of subexpressions. |
---|
283 | |
---|
284 | It might be possible to make better code by paying attention |
---|
285 | to the order in which to generate code for subexpressions of an expression. |
---|
286 | |
---|
287 | * More code motion. |
---|
288 | |
---|
289 | Consider hoisting common code up past conditional branches or |
---|
290 | tablejumps. |
---|
291 | |
---|
292 | * Trace scheduling. |
---|
293 | |
---|
294 | This technique is said to be able to figure out which way a jump |
---|
295 | will usually go, and rearrange the code to make that path the |
---|
296 | faster one. |
---|
297 | |
---|
298 | * Distributive law. |
---|
299 | |
---|
300 | The C expression *(X + 4 * (Y + C)) compiles better on certain |
---|
301 | machines if rewritten as *(X + 4*C + 4*Y) because of known addressing |
---|
302 | modes. It may be tricky to determine when, and for which machines, to |
---|
303 | use each alternative. |
---|
304 | |
---|
305 | Some work has been done on this, in combine.c. |
---|
306 | |
---|
307 | * Can optimize by changing if (x) y; else z; into z; if (x) y; |
---|
308 | if z and x do not interfere and z has no effects not undone by y. |
---|
309 | This is desirable if z is faster than jumping. |
---|
310 | |
---|
311 | * For a two-insn loop on the 68020, such as |
---|
312 | foo: movb a2@+,a3@+ |
---|
313 | jne foo |
---|
314 | it is better to insert dbeq d0,foo before the jne. |
---|
315 | d0 can be a junk register. The challenge is to fit this into |
---|
316 | a portable framework: when can you detect this situation and |
---|
317 | still be able to allocate a junk register? |
---|
318 | |
---|
319 | 2. Simpler porting. |
---|
320 | |
---|
321 | Right now, describing the target machine's instructions is done |
---|
322 | cleanly, but describing its addressing mode is done with several |
---|
323 | ad-hoc macro definitions. Porting would be much easier if there were |
---|
324 | an RTL description for addressing modes like that for instructions. |
---|
325 | Tools analogous to genflags and genrecog would generate macros from |
---|
326 | this description. |
---|
327 | |
---|
328 | There would be one pattern in the address-description file for each |
---|
329 | kind of addressing, and this pattern would have: |
---|
330 | |
---|
331 | * the RTL expression for the address |
---|
332 | * C code to verify its validity (since that may depend on |
---|
333 | the exact data). |
---|
334 | * C code to print the address in assembler language. |
---|
335 | * C code to convert the address into a valid one, if it is not valid. |
---|
336 | (This would replace LEGITIMIZE_ADDRESS). |
---|
337 | * Register constraints for all indeterminates that appear |
---|
338 | in the RTL expression. |
---|
339 | |
---|
340 | 3. Other languages. |
---|
341 | |
---|
342 | Front ends for Pascal, Fortran, Algol, Cobol, Modula-2 and Ada are |
---|
343 | desirable. |
---|
344 | |
---|
345 | Pascal, Modula-2 and Ada require the implementation of functions |
---|
346 | within functions. Some of the mechanisms for this already exist. |
---|
347 | |
---|
348 | 4. More extensions. |
---|
349 | |
---|
350 | * Generated unique labels. Have some way of generating distinct labels |
---|
351 | for use in extended asm statements. I don't know what a good syntax would |
---|
352 | be. |
---|
353 | |
---|
354 | * A way of defining a structure containing a union, in which the choice of |
---|
355 | union alternative is controlled by a previous structure component. |
---|
356 | |
---|
357 | Here is a possible syntax for this. |
---|
358 | |
---|
359 | struct foo { |
---|
360 | enum { INT, DOUBLE } code; |
---|
361 | auto union { case INT: int i; case DOUBLE: double d;} value : code; |
---|
362 | }; |
---|
363 | |
---|
364 | * Allow constructor expressions as lvalues, like this: |
---|
365 | |
---|
366 | (struct foo) {a, b, c} = foo(); |
---|
367 | |
---|
368 | This would call foo, which returns a structure, and then store the |
---|
369 | several components of the structure into the variables a, b, and c. |
---|
370 | |
---|
371 | 5. Generalize the machine model. |
---|
372 | |
---|
373 | * Some new compiler features may be needed to do a good job on machines |
---|
374 | where static data needs to be addressed using base registers. |
---|
375 | |
---|
376 | * Some machines have two stacks in different areas of memory, one used |
---|
377 | for scalars and another for large objects. The compiler does not |
---|
378 | now have a way to understand this. |
---|
379 | |
---|
380 | 6. Useful warnings. |
---|
381 | |
---|
382 | * Warn about statements that are undefined because the order of |
---|
383 | evaluation of increment operators makes a big difference. Here is an |
---|
384 | example: |
---|
385 | |
---|
386 | *foo++ = hack (*foo); |
---|
387 | |
---|
388 | 7. Better documentation of how GCC works and how to port it. |
---|
389 | |
---|
390 | Here is an outline proposed by Allan Adler. |
---|
391 | |
---|
392 | I. Overview of this document |
---|
393 | II. The machines on which GCC is implemented |
---|
394 | A. Prose description of those characteristics of target machines and |
---|
395 | their operating systems which are pertinent to the implementation |
---|
396 | of GCC. |
---|
397 | i. target machine characteristics |
---|
398 | ii. comparison of this system of machine characteristics with |
---|
399 | other systems of machine specification currently in use |
---|
400 | B. Tables of the characteristics of the target machines on which |
---|
401 | GCC is implemented. |
---|
402 | C. A priori restrictions on the values of characteristics of target |
---|
403 | machines, with special reference to those parts of the source code |
---|
404 | which entail those restrictions |
---|
405 | i. restrictions on individual characteristics |
---|
406 | ii. restrictions involving relations between various characteristics |
---|
407 | D. The use of GCC as a cross-compiler |
---|
408 | i. cross-compilation to existing machines |
---|
409 | ii. cross-compilation to non-existent machines |
---|
410 | E. Assumptions which are made regarding the target machine |
---|
411 | i. assumptions regarding the architecture of the target machine |
---|
412 | ii. assumptions regarding the operating system of the target machine |
---|
413 | iii. assumptions regarding software resident on the target machine |
---|
414 | iv. where in the source code these assumptions are in effect made |
---|
415 | III. A systematic approach to writing the files tm.h and xm.h |
---|
416 | A. Macros which require special care or skill |
---|
417 | B. Examples, with special reference to the underlying reasoning |
---|
418 | IV. A systematic approach to writing the machine description file md |
---|
419 | A. Minimal viable sets of insn descriptions |
---|
420 | B. Examples, with special reference to the underlying reasoning |
---|
421 | V. Uses of the file aux-output.c |
---|
422 | VI. Specification of what constitutes correct performance of an |
---|
423 | implementation of GCC |
---|
424 | A. The components of GCC |
---|
425 | B. The itinerary of a C program through GCC |
---|
426 | C. A system of benchmark programs |
---|
427 | D. What your RTL and assembler should look like with these benchmarks |
---|
428 | E. Fine tuning for speed and size of compiled code |
---|
429 | VII. A systematic procedure for debugging an implementation of GCC |
---|
430 | A. Use of GDB |
---|
431 | i. the macros in the file .gdbinit for GCC |
---|
432 | ii. obstacles to the use of GDB |
---|
433 | a. functions implemented as macros can't be called in GDB |
---|
434 | B. Debugging without GDB |
---|
435 | i. How to turn off the normal operation of GCC and access specific |
---|
436 | parts of GCC |
---|
437 | C. Debugging tools |
---|
438 | D. Debugging the parser |
---|
439 | i. how machine macros and insn definitions affect the parser |
---|
440 | E. Debugging the recognizer |
---|
441 | i. how machine macros and insn definitions affect the recognizer |
---|
442 | |
---|
443 | ditto for other components |
---|
444 | |
---|
445 | VIII. Data types used by GCC, with special reference to restrictions not |
---|
446 | specified in the formal definition of the data type |
---|
447 | IX. References to the literature for the algorithms used in GCC |
---|
448 | |
---|