Stack allocation

[David Brown]

On 18/11/2011 14:38, Alexandru Juncu wrote:
> On Fri, Nov 18, 2011 at 1:24 PM, David Brown<david@westcontrol.com>  wrote:
>> On 18/11/2011 10:27, Alexandru Juncu wrote:
>>>
>>> Hello!
>>>
>>> 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?
>>>
>>> Thank you!
>>>
>>
>> This is the wrong mailing list for questions like this - this is the list
>> for development of gcc itself, rather than for using it.
>
> Thank you for still answering. I apologize, but I looked at the lists
> and this one seemed the most generic.  Can you redirect me to another
> list where this thread would be appropriate?

That would be gcc-help@gcc.gnu.org.

There is a certain amount of overlap between the lists, and many (most?) 
of the gcc developers follow both of them.

>
>>
>> However, in answer to your question, the compiler will try to keep the stack
>> aligned in units of a suitable size for the processor architecture in use.
>>   Typically, the processor will be most efficient if the stack is aligned
>> with cache lines.  I don't know the details of the x86, but presumably
>> (level 1) cache lines are 16 bytes wide - or at least, that number fits
>> things like internal bus widths, prefetch buffers, etc. Thus the compiler
>> makes the tradeoff of using slightly more memory to improve the speed of the
>> program.
>
> I tried to compile with --param l1-cache-size... nothing seemed to change.
>

That would only affect the cache size in total, not the cache line width 
- "--param l1-cache-line-size" is the one you are looking for.  And 
there are other reasons why a 16-byte stack alignment might be 
considered optimal for the x86, so even if you change 
"l1-cache-line-size" it might not change the stack alignment.