On Fri, Jul 4, 2025 at 10:21 AM H.J. Lu <hjl.to...@gmail.com> wrote: > > On Fri, Jul 4, 2025 at 4:10 PM H.J. Lu <hjl.to...@gmail.com> wrote: > > > > On Fri, Jul 4, 2025 at 4:09 PM H.J. Lu <hjl.to...@gmail.com> wrote: > > > > > > On Fri, Jul 4, 2025 at 4:02 PM Richard Biener > > > <richard.guent...@gmail.com> wrote: > > > > > > > > > > > /* If we can't trust the parm stack slot to be aligned enough for its > > > ultimate type, don't use that slot after entry. We'll make another > > > stack slot, if we need one. */ > > > if (stack_parm > > > && ((GET_MODE_ALIGNMENT (data->nominal_mode) > MEM_ALIGN > > > (stack_parm) > > > && ((optab_handler (movmisalign_optab, data->nominal_mode) > > > != CODE_FOR_nothing) > > > || targetm.slow_unaligned_access (data->nominal_mode, > > > MEM_ALIGN (stack_parm)))) > > > || (data->nominal_type > > > && TYPE_ALIGN (data->nominal_type) > MEM_ALIGN (stack_parm) > > This is true. > > > > && MEM_ALIGN (stack_parm) < PREFERRED_STACK_BOUNDARY))) > > This is false as both are 16 bytes. This means that we only make a copy if > the > argument alignment < 16 bytes and the desired alignment > the argument > alignment. > It isn't the case here.
I don't know the exact history of this code (I just was aware we have such code), nor the reasoning for this exception. IMO this is a correctness issue, I could understand < BIGGEST_ALIGNMENT or so (no possible move insn could require bigger alignment), but even then the GIMPLE optimizers could have taken advantage of bigger alignment (for example the vectorizer happily will, emitting aligned moves). Having a copy is less than ideal, of course. If the alignment on the type is never too big (see test coverage in my other mail) then we could argue to ignore DECL_ALIGN on PARM_DECLs and instead set that to what the target thinks in the first place when creating the decl. Richard. > > > > > stack_parm = NULL; > > > > > > (gdb) call debug (stack_parm) > > > (mem/c:BLK (reg/f:DI 92 virtual-incoming-args) [2 f+0 S32 A128]) > > > (gdb) call debug (data->nominal_type) > > > <record_type 0x7fffe99cc348 c sizes-gimplified BLK > > > size <integer_cst 0x7fffe98242d0 type <integer_type 0x7fffe98220a8 > > > bitsizetype> constant 256> > > > unit-size <integer_cst 0x7fffe98243a8 type <integer_type > > > 0x7fffe9822000 sizetype> constant 32> > > > user align:256 warn_if_not_align:0 symtab:0 alias-set -1 > > > canonical-type 0x7fffe99cc2a0 > > > fields <field_decl 0x7fffe98318c0 a > > > type <real_type 0x7fffe982a3f0 long double sizes-gimplified XF > > > size <integer_cst 0x7fffe9802fa8 constant 128> > > > unit-size <integer_cst 0x7fffe9802fc0 constant 16> > > > align:128 warn_if_not_align:0 symtab:0 alias-set 1 > > > canonical-type 0x7fffe982a3f0 precision:80 > > > pointer_to_this <pointer_type 0x7fffe982aa80>> > > > XF z.c:2:15 size <integer_cst 0x7fffe9802fa8 128> unit-size > > > <integer_cst 0x7fffe9802fc0 16> > > > align:128 warn_if_not_align:0 offset_align 128 > > > decl_not_flexarray: 1 > > > offset <integer_cst 0x7fffe9802f90 constant 0> > > > bit-offset <integer_cst 0x7fffe9802fd8 constant 0> context > > > <record_type 0x7fffe99cc2a0> > > > chain <field_decl 0x7fffe9831960 b type <real_type > > > 0x7fffe982a3f0 long double> > > > XF z.c:3:15 size <integer_cst 0x7fffe9802fa8 128> > > > unit-size <integer_cst 0x7fffe9802fc0 16> > > > align:128 warn_if_not_align:0 offset_align 128 > > > decl_not_flexarray: 1 offset <integer_cst 0x7fffe9802fc0 16> > > > bit-offset <integer_cst 0x7fffe9802fd8 0> context <record_type > > > 0x7fffe99cc2a0>>> > > > pointer_to_this <pointer_type 0x7fffe99cc150>> > > > (gdb) > > > > > > It doesn't check DECL_USER_ALIGN. > > > > > > -- > > > H.J. > > > > Nowhere in function.cc DECL_USER_ALIGN is checked. > > > > -- > > H.J. > > > > -- > H.J.
