On Tue, Jun 9, 2026 at 5:17 PM LIU Hao <[email protected]> wrote: > > 在 2026-6-9 22:52, Jonathan Yong 写道: > > On 6/9/26 07:48, Richard Biener wrote: > > +CC: LH > > > >> On Sat, Jun 6, 2026 at 2:34 PM Oleg Tolmatcev <[email protected]> > >> wrote: > >>> > >>> From: oltolm <[email protected]> > >>> > >>> Fix PR54412 by preserving over-alignment for stack slots used for > >>> indirect argument passing and returns on Win64 targets that require it. > >>> > >>> On x86_64-w64-mingw32, TARGET_SEH limits > >>> MAX_SUPPORTED_STACK_ALIGNMENT to 128 bits, but fixed-size AVX and > >>> AVX512 values can still require greater alignment when passed or > >>> returned indirectly. Generic stack-slot allocation can therefore > >>> produce under-aligned slots, leading to misaligned aligned-move > >>> accesses and runtime failures. > >> > >> I think this is a x86 specific bug in how it optimizes things, the target > >> uses > >> carefully orchestrated code to "optimize" "unnecessary" alignment, so I > >> suspect the proper fix would be to x86 target code, not to complicate the > >> middle-end side. But see below for comments on the patch. > >> > >> What's the actual reason TARGET_SEH sets MAX_SUPPORTED_STACK_ALIGNMENT > >> to 128 (thus, disables stack re-alignment)? > > The reason for that is that SEH unwinding format is incapable of encoding a > realignment operation: > > > https://learn.microsoft.com/en-us/cpp/build/exception-handling-x64?view=msvc-170#raw-pseudo-operations > > These opcodes are emitted in a prologue like this > > push rbp > .seh_pushreg rbp > push rdi > .seh_pushreg rdi > push rsi > .seh_pushreg rsi > sub rsp, 288 > .seh_stackalloc 288 > lea rbp, [rsp + 128] > .seh_setframe rbp, 128 > .seh_endprologue > > A realignment operation such as `and rsp, -32` would allocate an unknown > number of bytes and is not > encodeable.
I see, that makes sense. > > > > > -- > Best regards, > LIU Hao
