This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
But arent there subtle side effects optimizations might need to consider
If so, can't we simply expose the calls to malloc/free at the begin/end of the BIND_EXPR and not have to worry about any magic or new tree codes?
These new magic codes require about the same amount of handling as these
functions need. In fact I have considered making them just specially
handled function calls; but it seemed to be cleaner this way to me.
that a function call would expose, or that they need to be taught about
the new opcode?
ie something like:
int x,y; { x = call1(); y = call2(); { int a[y]; { int b[x]; ... } }
if we switch this to magic opcodes, we'd see something like:
int x,y x = call1() y = call2() a = STACK_ALLOC (y) b = STACK_ALLOC(x) STACK_DEALLOC (b) STACK_DEALLOC (a)
there is no ordering implied any more with the BIND_EXPR's gone, so code
motion could then make this:
Right.
x = call1() b = STACK_ALLOC (x) y = call2() a = STACK_ALLOC(y) STACK_DEALLOC (b) STACK_DEALLOC (a)
which is going to deallocate them in the wrong order.
If they are represented as calls, then the allocation of b would not get
moved above the allocation of a because we already understand enough
about them to know we cant do this.
Or you have to teach the SSA renamer to provde a special virtual operand
variable to keep the ordering properly. something like:
int x,y x = call1() y = call2() # stack_alloc_1 = VDEF <stack_alloc_0> a = STACK_ALLOC (y) # stack_alloc_2 = VDEF <stack_alloc_1> b = stack_ALLOC(x) # VUSE <stack_alloc_2> STACK_DEALLOC (b) # VUSE <stack_alloc_1> STACK_DEALLOC (a)
Same thing holds true for the DEALLOCS. There doesnt appear to be any
reson why the DEALLOC use can't be moved right up to the def point. Uses
can be moved by each other unless there are side effects...
Andrew
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |