Hi, On Mon, 24 Mar 2014, Richard Biener wrote:
> Maybe somebody remembers why we have both paths. I'd rather make > gimplification independent of this as well, choosing either variant. I can't say why we have the !PUSH_ARGS_REVERSED path (so I guess that's the way that initially was there, before the distinction was made), but the PUSH_ARGS_REVERSED==1 path is important when you have push instructions and arguments grow in the opposite direction of the stack. The latter is the case for almost all targets, so as soon as you have push instructions (and no ACCUMULATE_OUTGOING_ARGS) you'll want to have PUSH_ARGS_REVERSED==1 as well. I guess the !PUSH_ARGS_REVERSED path only has advantages for the few targets where stack and args grow the same way and that use push instructions for argument passing, which currently are none. pa-64 does have same-direction arguments and stack (both upward), but doesn't use push, and the only other ARGS_GROW_DOWNWARD (pa-32bit and stormy16) also have !STACK_GROWS_DOWNWARD, so again opposite direction. Without push instructions or with ACCUMULATE_OUTGOING_ARGS I guess it doesn't matter much for parameters passed in memory (the offsets simply will be N to 0 instead of 0 to N), and for register arguments there's a slight advantage for PUSH_ARGS_REVERSED==1 for the usual case of same-ordered arguments passed down, like in James' example. > Do you have any hard numbers to compare? Say cc1 code size, when > comparing PUSH_ARGS_REVERSED 1 vs 0? If we'd agree on only one way, then it must be PUSH_ARGS_REVERSED==1. That would be a change in argument gimplification (and hence eval) order for many targets, and could result in unexpected side-effects for invalid code, like James said. IMO no reason to not try that in stage 1, though. Ciao, Michael.