On Fri, 11 Sep 2026, Richard Biener wrote: > On Fri, 11 Sep 2026, Richard Biener wrote: > > > 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). > > Ah, I see HJ left in the < MAX_SUPPORTED_STACK_ALIGNMENT checks > that I said were bogus: > > || (data->nominal_type > && TYPE_ALIGN (data->nominal_type) > MEM_ALIGN (stack_parm) > && ((MEM_ALIGN (stack_parm) > < MIN (BIGGEST_ALIGNMENT, > MAX_SUPPORTED_STACK_ALIGNMENT)) > /* If its address is taken, make a local copy whose > maximum alignment is MAX_SUPPORTED_STACK_ALIGNMENT. > */ > || (TREE_ADDRESSABLE (parm) > && (MEM_ALIGN (stack_parm) > < MAX_SUPPORTED_STACK_ALIGNMENT)))))) > > so this shoud be > > MEM_ALIGN (stack_parm) < BIGGEST_ALIGNMENT > || TREE_ADDRESSABLE (parm) > > though the TREE_ADDRESSABLE case could be left as-is for the testcase > at hand (that's for the case the alignment escapes and thus can be > asserted by the user).
Ah, the TREE_ADDRESSABLE should be gated by sth like MEM_ALIGN (stack_parm) < MAX (targetm.absolute_biggest_alignment, MAX_SUPPORTED_STACK_ALIGNMENT) as if the slot escapes to another function that might be compiled with -mavx512 which ups BIGGEST_ALIGNMENT there. I'll note that hook seems to be unused apart from in LTO streaming to accelerators. Richard. > Richard. > > > > > 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)
