пт, 11 сент. 2026 г. в 14:46, Richard Biener <[email protected]>: > > 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.
On Win64, x is passed by reference, so that function compares the alignment of the pointer, 8 bytes, with the alignment of its home slot, also 8 bytes, and none of the checks in assign_parm_adjust_stack_rtl is true. The copy of the 32-byte object x is made in the pass_by_reference block of assign_parm_setup_reg, which calls assign_stack_local, so the slot is capped at 128 bits, and set_mem_attributes then raises MEM_ALIGN to 256. Only assign_parm_setup_block realigns at run time, which is why my patch changes assign_parm_setup_reg and assign_parm_setup_stack too. Oleg
