On 11/18/2011 03:03 PM, Alexandru Juncu wrote:
> Hello!
>
> [I sent an email on the gcc main list by my mistake, and I am moving
> the discussion here]
>
> I have a curiosity with something I once tested. I took a simple C
> program and made an assembly file with gcc -S.
>
> The C file looks something like this:
> int main(void)
> {
> int a=1, b=2;
> return 0;
> }
>
> The assembly instructions look like this:
>
> subl $16, %esp
> movl $1, -4(%ebp)
> movl $2, -8(%ebp)
>
> The subl $16, means the allocation of local variables on the stack,
> right? 16 bytes are enough for 4 32bit integers.
> If I have 1,2,3 or 4 local variables declared, you get those 16 bytes.
> If I have 5 variables, we have " subl $32, %esp". 5,6,7,8 variables ar
> the same. 9, 10,11,12, 48 bytes.
>
> The observation is that gcc allocates increments of 4 variables (if
> they are integers). If I allocate 8bit chars, increments of 16 chars.
>
> So the allocation is in increments of 16 bytes no matter what.
>
> OK, that's the observation... my question is why? What's the reason
> for this, is it an optimization (does is matter what's the -O used?)
> or is it architecture dependent (I ran it on x86) and is this just in
> gcc, just in a certain version of gcc or this is universal?
>
> I got a response that is related to the cache line alignment, to
> optimize cache hits.
> But I tried to compile the program with the --param l1-cache-size and
> got the same .s file. Is this ok?
You're not optimizing. Nothing much will happen with optimization options
when you're not optimizing.
This is x86-specific, but other processors have similar needs.
gcc must 16-align the stack because some structures (such as MMX data)
must be aligned. Given that the data must be aligned, so must the stack.
Also, fetches and stores that straddle cache line boundaries can be very
slow.
Andrew.
