wilson@carcoar.Stanford.EDU (Paul Wilson) (02/03/90)
I'm trying to evaluate the back end of GCC as a potential back end for languages like Lisp or Smalltalk. For this I need to know how hard it would be to clue the optimizer in about certain stereotypical Lispy and Smalltalky kinds of things. I realize that reg notes can be used to tell the optimizer when a value dies. I would like to use this to help the optimizer get rid of unnecessary sequences of stack pushes and pops. My question is this -- if I have a reg I'm using as a stack pointer, can I express in RTL that the *memory* location that the stack pointer points at holds a dead value? That is, can I express that a memory value, as opposed to a register value, is dead? (Note that I'm talking about implementing my own stack for my own purposes by writing PUSH and POP in RTL. I'm *not* talking about pushing and popping the standard C stack.) Similarly, can I use a reg note to declare that a value pointed at by (an offset from) one pointer is the same as a value pointed at by (an offset from) another pointer, so that redundant comparisons will be taken out at compile time? What this boils down to is this -- how smart is GCC about doing dataflow analysis through memory locations referred to by (offsets from) pointers? Does it by default create a pseudo-reg to cache a memory value, and only generate RTL to flush the value back to memory in the case of a potentially aliased pointer reference? Or does it simply punt in the case of memory references, and only optimize across dataflow through explicit (real or pseudo-) registers? For example, if I push 23 onto my virtual machine's stack, and then pop the value off and shove it into variable y, can I express the fact1 that the value 23 above my stack pointer is garbage, and that only the value in y should be ensured by the optimizer? I want to insert a reg note in the code for a stack pop that says anything above the stack pointer (the value pointed at befere the pop) dies. I want the optimizer to infer that the net effect of pushing 23 and popping it into a variable is simply to move 23 into the variable; it should skip the incrementing and decrementing of the stack pointer, as well as the storing into the stack location. It seems that it would be useful for GCC to be able to tell when a location at one offset from a pointer is identical to a location a different offset from the same poiner once the pointer has been incremented or decremented by a compile-time constant. (E.g., in the case of loop optimization of iterating through an an array. It could tell whether successive unrolled iterations of the loop refer to same or different elements, and do dataflow analysis accordingly.) Am I dreaming? If so, it seems like I may be much better off with a virtual machine that passes arguments in registers, instead of on the stack. Then GCC would have a better shot at seeing how values move around, and optimizing many of the moves away. Even if a register- based VM is not better in general, it would be advantageous in making it easier for the GCC backend to see opportunities for optimization. Any info relevant to this, or pointers to info relevant to this, would be greatly appreciated. Thanks prematurely, Paul Paul R. Wilson Software Systems Laboratory lab ph.: (312) 996-9216 U. of Illin. at C. EECS Dept. (M/C 154) wilson@bert.eecs.uic.edu Box 4348 Chicago,IL 60680 Paul R. Wilson Software Systems Laboratory lab ph.: (312) 996-9216 U. of Illin. at C. EECS Dept. (M/C 154) wilson@carcoar.stanford.edu Box 4348 Chicago,IL 60680