On Fri, 11 Sep 2026, Oleg Tolmatcev wrote: > пт, 11 сент. 2026 г. в 13:54, Richard Biener <[email protected]>: > > > > On Fri, 11 Sep 2026, H.J. Lu wrote: > > > > > On Fri, Aug 28, 2026 at 12:57 AM Oleg Tolmatcev > > > <[email protected]> wrote: > > > > > > > > Targets that cannot realign the stack cap their stack alignment and rely > > > > on the middle end to align over-aligned stack objects inside their > > > > slots. > > > > Win64 SEH caps MAX_STACK_ALIGNMENT at 128 bits; aarch64 does not define > > > > MAX_STACK_ALIGNMENT at all and is capped at STACK_BOUNDARY, also 128. > > > > > > > > In several places the middle end does not do that alignment. A 256-bit > > > > vector requires 32-byte alignment, its slot gets the capped 16 bytes, > > > > and > > > > MEM_ALIGN is set to 32 anyway. x86 selects vmovaps from MEM_ALIGN and > > > > > > The easiest way is to use vmovups on stack if MEM_ALIGN > > > > MAX_STACK_ALIGNMENT. > > > > That sounds pragmatic, but IL is still wrong then. What is a > > minmal testcase to trigger the issue you are fixing with this patch? > > The PR is a bit hard to sort through. > > > > Richard. > > The minimal test case is > gcc/testsuite/gcc.target/i386/pr54412-m256-byval-param.c from the > testsuite patch of this series, compiled for x86_64-w64-mingw32 with > -O0 -mavx -S: > > #include <immintrin.h> > > void > foo (__m256 x) > { > (void) x; > } > > The home slot of x is only 16-byte aligned, because > assign_stack_local_1 caps it at MAX_SUPPORTED_STACK_ALIGNMENT, which > is 128 bits on Windows SEH. But set_mem_attributes then raises its > MEM_ALIGN to the 256 bits of the type, so GCC uses vmovaps, which > faults if the slot does not happen to be 32-byte aligned. > > Here is a minimal test case for an escaping pointer to a misaligned slot: > > typedef float v8sf __attribute__ ((vector_size (32))); > > __attribute__ ((noipa)) v8sf > get (const v8sf *p) > { > return *p; > } > > v8sf > f (v8sf x) > { > return get (&x); > } > > f stores x to its misaligned home slot and passes the address to get, > which loads it with vmovaps (%rax).
OK, so I think your fix is on the right track, I just do not like to restrict it by adding a new API. Note that I expected the second testcase to work already - we should be doing a copy of 'x' to a properly aligned stack slot and pass that to 'get', and the code doing that should handle runtime re-aligning already. Maybe it's still wrong in detail? It should be the code that's last touched by r16-8383-gcc33cf487524e7 (assign_parm_adjust_stack_rtl). Richard. > > Oleg > -- Richard Biener <[email protected]> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Stefan Gaiser, Jochen Jaser, Abhinav Puri; (HRB 36809, AG Nuernberg)
