Re: [avr-llvm-devel] Current Status?

[Borja F. <bor...@gm...>]

For now I've implemented it the same way as gcc, but it's something that
popped to me when i was coding it.
I don't see how it saves space :) what I think is that you get the same
amount of pushes and std's when moving data into the stack no matter what
method is used. The difference I see is that when using std, you have to
adjust the SP pointer which creates an additional overhead. Just to clarify
I'm talking about the case when you want to pass function arguments before
a function call, not in a function prologue which is a different story.

In x86 it would be something like:

sub esp, 8
mov DWORD PTR [esp], reg1
mov DWORD PTR [esp+4], reg 2
call foo
...

instead of

push reg1
push reg2
call foo
...

which saves 1 instruction, but in our case doing "sub esp, 8" means adding
5 or 6 more instructions.

2012/1/12 Weddington, Eric <Eri...@at...>

>
> > -----Original Message-----
> > From: Borja Ferrer [mailto:bor...@gm...]
> > Sent: Thursday, January 12, 2012 10:14 AM
> > To: Weddington, Eric
> > Cc: Sherard Dames; avr...@li...
> > Subject: Re: [avr-llvm-devel] Current Status?
> >
> > Eric I have one question, when passing function parameters through the
> > stack, why does gcc allocate stack space doing the typical copy from
> SP to
> > a reg, decrement it for the needed amount and then copy it back to SP
> and
> > then use std instructions, instead of directly pushing the registers
> > saving all the SP manipulation?
> > Is there particular reason for not doing this?
> >
>
> I can only speculate on why GCC does that, and that would be to probably
> save on code space. It depends (or, at least, it *should* depend) on how
> much data is being passed as parameters. It might be smaller to do:
> 1. copy SP to reg
> 2. decrement reg by needed amount
> 3. copy reg back to SP
> than it would be to do multiple pushes.
>
> But, again, I stress that I'm just speculating as to why it would be the
> case.
>
> For llvm, I would suggest that you do as you see fit, as long as it's
> *correct* code, and then let's go back later to optimize it. If you
> think it is easier to deal with doing all pushes, then go ahead and
> implement it. Then we'll look at the code output.
>
> Eric Weddington
>