Re: [RFC] Remove PUSH_ARGS_REVERSED from the RTL expander.

[Michael Matz <matz at suse dot de>]

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.