--- gcc/PROJECTS 2018/04/24 16:50:04 1.1.1.4 +++ gcc/PROJECTS 2018/04/24 16:52:25 1.1.1.6 @@ -1,3 +1,10 @@ +0. Improved efficiency. + +* Parse and output array initializers an element at a time, freeing +storage after each, instead of parsing the whole initializer first and +then outputting. This would reduce memory usage for large +initializers. + 1. Better optimization. * Constants in unused inline functions @@ -49,9 +56,9 @@ This brings to mind Hayes' changes for S * 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 -that anything that might be that location (including no reference -to a variable address). +the same location; and, in between, there is no reference to anything +that might be that location (including no reference to a variable +address). * Loop optimization. @@ -59,7 +66,7 @@ Strength reduction and iteration variabl 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 iable and create +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 @@ -169,6 +176,13 @@ d0 can be a junk register. The challeng a portable framework: when can you detect this situation and still be able to allocate a junk register? +* For the 80387 floating point, perhaps it would be possible to use 3 +or 4 registers in the stack to hold register variables. (It would be +necessary to keep track of how those slots move in the stack as other +pushes and pops are done.) This is probably very tricky, but if +you are a GCC wizard and you care about the speed of floating point on +an 80386, you might want to work on it. + 2. Simpler porting. Right now, describing the target machine's instructions is done @@ -207,41 +221,6 @@ where static data needs to be addressed for scalars and another for large objects. The compiler does not now have a way to understand this. -* Some machines use a caller-saves convention for saving registers over -function calls. Here is a design for how to handle such a convention. - -Classify all the hard registers as call-clobbered, then teach the -compiler how to put call-crossing pseudo-regs in call-clobbered hard -registers by generating save/restore insns around the call. Generate -the save/restores somewhere around the reload pass; this avoids -getting confused by cross jumping which happens after. Actually put -the save/restore insns into the RTL chain, so that cross-jumping and -peephole opt. will work on them. - -The time to generate these insns is when you can still tell what regs -are live at each call, but late enough to know exactly where the -pseudos have been allocated. Perhaps the best time is just before -reload_as_needed. - -This requires changes in local-alloc.c and global-alloc.c to be willing -to allocate call-crossing pseudos to call-clobbered registers. -That isn't hard if you do it with a special flag macro that simply says to -ignore (in those passes) whether a register is call-clobbered. -This macro would be defined if the target machine uses caller-saves. - -To get the best output, it is necessary to count the cost (in -additional save/restores) for each pseudo register of putting it in a -call-clobbered hard reg. This means counting *how many times* each -pseudo crosses a call. Depending on that value, it might be better to -put the pseudo in memory than in a call-clobbered register. Cost -counting would be done in flow.c, perhaps, and costs would affect -allocation decisions in local-alloc and global-alloc. Perhaps each -pseudo should have one priority for getting a call-saved reg and -another, lower (in general) priority for a call-clobbered reg. - -Then there would no longer be a need for the flag: the changes would -improve the output, on all machines. - 5. Precompilation of header files. In the future, many programs will use thousands of lines of header files. @@ -311,20 +290,9 @@ The second step is to divide the output some unconditional. This division is done without changing the order of the text being divided up. -6. Other possibly nice features. - -* cpp could have a #provide directive. -#provide would have the same syntax as #include, -and it would nullify any future #include directive -with the same argument. Thus, the file foo.h -could contain #provide to prevent itself from -being included twice. - -This is much cleaner than the alternative sometimes implemented, -which is to require the user to use something other than #include -in order to ensure inclusion only once. +JNC@lcs.mit.edu has some ideas on this subject also. -7. Better documentation of how GCC works and how to port it. +6. Better documentation of how GCC works and how to port it. Here is an outline proposed by Allan Adler. @@ -363,7 +331,7 @@ VI. Specification of what constitutes A. The components of GCC B. The itinerary of a C program through GCC C. A system of benchmark programs - D. What your RTL and assembler look should like with these benchmarks + D. What your RTL and assembler should look like with these benchmarks E. Fine tuning for speed and size of compiled code VII. A systematic procedure for debugging an implementation of GCC A. Use of GDB