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
On 26/04/14 14:25, Eric Botcazou wrote:
>>> 2014-03-21 James Greenhalgh
>>>
>>> * 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
> > 2014-03-21 James Greenhalgh
> >
> > * 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.
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 o
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_REVER
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 th
On Mon, Mar 24, 2014 at 11:54:49AM +, Richard Biener wrote:
> On Mon, Mar 24, 2014 at 12:44 PM, James Greenhalgh
> 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,
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, be
On Mon, Mar 24, 2014 at 12:44 PM, James Greenhalgh
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
>
> r0 = b
>
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
r0 = b
r1 = c
r2 = d
If we process arguments to the call to foo left-to-right
(PUSH_ARGS_R
10 matches
Mail list logo
