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. jeff
