Stack parameter - pass by value - frame usage

Stack parameter - pass by value - frame usage

[Hariharan Sandanagobalane]

Hello,
I looked at an inefficient code sequence for a simple program using 
GCC's picochip port (not yet submitted to mainline). Basically, a 
program like

long carray[10];
void fn (long c, int i)
{
  carray[i] = c;
}

produces good assembly code. But, if i were to do

struct complex16
{
int re,im;
};

struct complex16 carray[10];

void fn (struct complex16 c, int i)
{
  carray[i] = c;
}

GCC generates poor code. It has an extra save and restore of the 
frame-pointer, even though we dont use the frame.

I digged a bit further, and found that the get_frame_size() call returns 
4 in this case and hence the port's prologue generation code generates 
the frame-pointer updation.

It seems to me that each element of the stack is copied to the stack 
from the parameter registers and then that value is being used in the 
function. I have the following RTL code as we get into RTL.

(insn 6 2 7 2 (set (reg:HI 26)
        (reg:HI 0 R0 [ c ])) -1 (nil)
    (nil))

(insn 7 6 10 2 (set (reg:HI 27)
        (reg:HI 1 R1 [ c+2 ])) -1 (nil)
    (nil))

(insn 10 7 8 2 (set (reg/v:HI 28 [ i ])
        (reg:HI 2 R2 [ i ])) -1 (nil)
    (nil))

(insn 8 10 9 2 (set (mem/s/c:HI (reg/f:HI 21 virtual-stack-vars) [3 c+0 
S2 A16])
        (reg:HI 26)) -1 (nil)
    (nil))

(insn 9 8 11 2 (set (mem/s/c:HI (plus:HI (reg/f:HI 21 virtual-stack-vars)
                (const_int 2 [0x2])) [3 c+2 S2 A16])
        (reg:HI 27)) -1 (nil)
    (nil))

Note that the parameter is being written to the frame in the last 2 
instructions above. This, i am guessing is the reason for the 
get_frame_size() returning 4 later on, though the actual save of the 
struct parameter value on the stack is being eliminated at later 
optimization phases (CSE and DCE, i believe).

Why does the compiler do this? I vaguely remember x86 storing all 
parameter values on stack. Is that the reason for this behaviour? Is 
there anything i can do in the port to get around this problem?

Note : In our port "int" is 16-bits and long is 32-bits.

Thanks in advance,

Regards
Hari

Re: Stack parameter - pass by value - frame usage

[Ian Lance Taylor]

Hariharan Sandanagobalane <hariharans@picochip.com> writes:

> I looked at an inefficient code sequence for a simple program using
> GCC's picochip port (not yet submitted to mainline).

Are you working with mainline sources?

> Note that the parameter is being written to the frame in the last 2
> instructions above. This, i am guessing is the reason for the
> get_frame_size() returning 4 later on, though the actual save of the
> struct parameter value on the stack is being eliminated at later
> optimization phases (CSE and DCE, i believe).
> 
> Why does the compiler do this? I vaguely remember x86 storing all
> parameter values on stack. Is that the reason for this behaviour? Is
> there anything i can do in the port to get around this problem?

At a guess, it's because the frontend decided that the struct was
addressable and needed to be pushed on the stack.  I thought this got
cleaned up recently, though.

Ian

Re: Stack parameter - pass by value - frame usage

[Hariharan Sandanagobalane]

Ian Lance Taylor wrote:
> Hariharan Sandanagobalane <hariharans@picochip.com> writes:
> 
>> I looked at an inefficient code sequence for a simple program using
>> GCC's picochip port (not yet submitted to mainline).
> 
> Are you working with mainline sources?

I was not. I tried the same with gcc 4.3 branch and it does fix most of 
the problems. There are still corner cases where it produces unoptimal 
code. I will try to figure out whats wrong in those and get back to you.

Regards
Hari

> 
>> Note that the parameter is being written to the frame in the last 2
>> instructions above. This, i am guessing is the reason for the
>> get_frame_size() returning 4 later on, though the actual save of the
>> struct parameter value on the stack is being eliminated at later
>> optimization phases (CSE and DCE, i believe).
>>
>> Why does the compiler do this? I vaguely remember x86 storing all
>> parameter values on stack. Is that the reason for this behaviour? Is
>> there anything i can do in the port to get around this problem?
> 
> At a guess, it's because the frontend decided that the struct was
> addressable and needed to be pushed on the stack.  I thought this got
> cleaned up recently, though.
> 
> Ian
This email and any files transmitted with it are confidential and intended solely for the use of the individuals to whom they are addressed. If you have received this email in error please notify the sender and delete the message from your system immediately.