push ebp
mov ebp, esp
and esp, -32
sub esp, 64  ; because it won't fit in 32-bytes and has to be aligned to 32 for some reason?    

push ebp
mov ebp, esp
sub esp, 36  ; since it only actually needs 36 bytes, it's sufficient
and esp, -32 ; and esp is STILL aligned to 32 bytes here    

I hope there is a way to make programs that not use ebp at all. This means no recursion and no callstack, but it's not that necessary anyway.

Furs: It is probably about being unaware and/or not caring. Many people these days treat memory as an infinite resource so "wasting" a few bytes here and there makes no big difference to them. Plus, the attitude of: it works so there is nothing to fix. The only real problem that could occur (aside from simply running out of memory) is cache thrashing causing some performance degradation, and naturally as everyone knows, performance issues are always solved by buying newer hardware.

tester1:
        push    ebp
        mov     ebp,esp
        and     esp,-32
        sub     esp,36

        vmovdqa [esp+4],ymm0    ;AVX local. Aligned location is at ESP+4
        mov     eax,[esp]       ;dword local

        mov     esp,ebp
        pop     ebp
        ret


tester2:
        push    ebp
        mov     ebp,esp
        sub     esp,36
        and     esp,-32     ;TOS is aligned to 32.

        vmovdqa [esp],ymm0      ;AVX local. Aligned location is at TOS.
        mov     eax,[esp+32]    ;dword local

        mov     esp,ebp
        pop     ebp
        ret     

Furs: It is probably about being unaware and/or not caring. Many people these days treat memory as an infinite resource so "wasting" a few bytes here and there makes no big difference to them. Plus, the attitude of: it works so there is nothing to fix. The only real problem that could occur (aside from simply running out of memory) is cache thrashing causing some performance degradation, and naturally as everyone knows, performance issues are always solved by buying newer hardware.

For those with complete mastery of stack programming, it doesn't really matter (add/sub or sub/add) because they know exactly where in aligned memory area to write/read the SSE/AVX data to/from amongst other local data and volatile registers in the stack frame. I am surprised that this kind of question came from you (the master of everything).

revolution wrote:

Furs: It is probably about being unaware and/or not caring. Many people these days treat memory as an infinite resource so "wasting" a few bytes here and there makes no big difference to them. Plus, the attitude of: it works so there is nothing to fix. The only real problem that could occur (aside from simply running out of memory) is cache thrashing causing some performance degradation, and naturally as everyone knows, performance issues are always solved by buying newer hardware.

Well that's of course what I also thought myself, but I wanted to ask to see if I was missing anything. I mean remember my rant about compilers never generating better code than hand-written asm, due to the developers not caring, not because of "technical limitations". To them keeping a compiler "simple" is more important than having better code generator for all the code they'll end up compiling it with. With such mentality, it is no wonder they will never beat hand-written asm code.

However this case really pisses me off since, well, the "swap" doesn't even require extra complications. Literally, just swap the and and sub (for GCC e.g. in ix86_expand_prologue hook) and then don't "round up" the stack size to the largest alignment (crtl->stack_alignment_needed used in reload). But I mean even if they still round up the stack (i.e. provide no gain), swapping the two produces no worse results, so it should still be done regardless, IMO.

I'm more annoyed because Clang and ICC do the same thing (or ICC used to, idk these days, can't check godbolt as it doesn't work for some reason), like seriously, why is everyone so incompetent?

Anyway, thanks for "confirming" my suspicions

system error wrote:

For those with complete mastery of stack programming, it doesn't really matter (add/sub or sub/add) because they know exactly where in aligned memory area to write/read the SSE/AVX data to/from amongst other local data and volatile registers in the stack frame. I am surprised that this kind of question came from you (the master of everything).

I will bite and be civil. First, it's "and" not "add".

It's not an arithmetic operation, it's a bitwise operation, which has the effect of conditionally performing arithmetic on it. No, you don't know where exactly the AVX variable is, because you don't have a 32-byte aligned stack pointer, deal with it. You need to conditionally subtract from it, which is what bitwise and does, and also to save it in ebp to be able to perform the same step "back" when exiting the function.

You don't control who calls your function and what stack address it has. Suppose your function gets called with these two stack addresses (before the call) 0x00400010 and then with address 0x00400020.

Last time I challenged you to show me code that "knows exactly where variables are", they were misaligned in one of the two cases. Fixing it for the other case resulting in the other case being misaligned. Your reply was just "LOL" in defeat.

So kindly, stop polluting a sensible thread when you have no idea what you're talking about.

Local variables? It's mentioned in the first post. I have a 256-bit AVX vector on the stack and an 4-byte int. 32+4 = 36, and to keep esp aligned (after the sub) to 32-byte the nearest is 64. Aligning esp after the subtraction, though, requires only a sub 36, because it gets aligned after anyway. If the sub 36 makes it misaligned, the bitwise and will align it. It guarantees there's at least 36 bytes of space, so [esp] will be aligned (and use the vector there).

The part where you use 2 functions when there should only be 1 working in both cases, moron. ONE function.

Uh, yeah it is, but [esp] is not aligned to 32-bytes, which seems to be important for compilers. I don't care what you think, the sub esp, 64 is generated by the COMPILER because it wants to keep it aligned to 32 for whatever reason.

On the other hand, your solution has virtually NO ADVANTAGE compared to mine. Mine has [esp] aligned to 32, yours [esp+4] (first one) using the same amount of space.

What the fuck are you even trying to argue about? Something obviously inferior and harder to get right by the compiler? Just to disagree with me?

Also, stop making double posts.

Man, you can't understand simple english? I didn't say your code doesn't have the vector aligned.

I said it doesn't have [esp] aligned, which is what the COMPILER wants to do. Your solution does not satisfy the compiler (hint: it's the purpose of the thread) and it also requires more work to change the compiler (it needs to keep alignment bias somewhere).

Now, your code also has zero advantage compared to mine, so tell me again, what exactly are you arguing about?