On Fri, Apr 25, 2014 at 09:15:57PM +0100, Jeff Law wrote: > On 03/24/14 05:44, James Greenhalgh wrote: > > Which is much neater. > > > > It seems to me that this would probably be of benefit on all targets. > > > > This would be an argument for setting PUSH_ARGS_REVERSED to 1 by default > > for all targets. However, this would have a perceivable impact on argument > > evaluation order (which is unspecified in C, but people have shown > > sensitivity to it changing in the past and we suspect some people may > > have built systems relying on the behviour... ho hum...). > > > > However, now that all side effects are handled when we are in SSA > > form, it should be possible to refactor calls.c and expr.c as if > > PUSH_ARGS_REVERSED were always defined to 1, without changing the > > argument evaluation order in gimplify.c. > > > > In this way, we have the best of both worlds; we maintain argument > > evaluation order and gain the optimizations given by removing > > overlapping live ranges for parameters. > > > > I've bootstrapped and regression tested this on x86, ARM and AArch64 - but > > I am well aware these are fairly standard targets, do you have any > > suggestions or comments on which targets this change will affect? > > > > If not, is this OK for stage-1? > > > > Thanks, > > James > > > > --- > > gcc/ > > > > 2014-03-21 James Greenhalgh <james.greenha...@arm.com> > > > > * calls.c (initialize_argument_information): Always treat > > PUSH_ARGS_REVERSED as 1, simplify code accordingly. > > (expand_call): Likewise. > > (emit_library_call_calue_1): Likewise. > > * expr.c (PUSH_ARGS_REVERSED): Do not define. > > (emit_push_insn): Always treat PUSH_ARGS_REVERSED as 1, simplify > > code accordingly. > This is fine for the trunk at this point. > > Sorry for the delay.
Thanks Jeff. I've committed this as revision 209897 after checking it still bootstraps across arm/aarch64/i386. I'll look out for any fallout on other targets, please shout if I've broken something! Thanks, James
