]>
Commit | Line | Data |
---|---|---|
967e4412 RM |
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 |