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

2014-04-29 Thread Richard Earnshaw
On 26/04/14 14:25, Eric Botcazou wrote: 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. *

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

2014-04-29 Thread James Greenhalgh
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.

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

2014-04-26 Thread Eric Botcazou
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

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

2014-04-25 Thread Jeff Law
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

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

2014-03-25 Thread Michael Matz
Hi, On Mon, 24 Mar 2014, Richard Henderson wrote: See http://en.wikipedia.org/wiki/X86_calling_conventions#pascal Since we don't actually support this anymore, we can certainly tidy this up. Yeah, I thought about that, but I couldn't see how that could have used PUSH_ARGS_REVERSED.

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

2014-03-24 Thread Richard Biener
On Mon, Mar 24, 2014 at 12:44 PM, James Greenhalgh james.greenha...@arm.com wrote: Hi, Consider this testcase: extern void foo (int a, int b, int c, int d); void bar (int b, int c, int d) { foo (3, b, c, d); } For many ABI's we will have on entry to the function

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

2014-03-24 Thread Michael Matz
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,

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

2014-03-24 Thread James Greenhalgh
On Mon, Mar 24, 2014 at 11:54:49AM +, Richard Biener wrote: On Mon, Mar 24, 2014 at 12:44 PM, James Greenhalgh james.greenha...@arm.com wrote: Hi, Consider this testcase: extern void foo (int a, int b, int c, int d); void bar (int b, int c, int d) { foo

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

2014-03-24 Thread Richard Henderson
On 03/24/2014 06:23 AM, Michael Matz wrote: 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