https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123447
Pengfei Li <pfustc at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pfustc at gcc dot gnu.org
--- Comment #4 from Pengfei Li <pfustc at gcc dot gnu.org> ---
With "-mstrict-align", the problematic RTL that triggers the ICE is:
(insn 12 11 13 2 (set (mem/c:XI (plus:DI (reg/f:DI 64 sfp)
(const_int -96 [0xffffffffffffffa0])) [0 S64 A8])
(reg:XI 103)) "a.c":14:6 4861 {*aarch64_movxi}
This insn stores a 64-byte vector constant of _Decimal64 into a stack slot. The
stack slot is created during expand via:
assign_stack_local (TYPE_MODE (TREE_TYPE (tem)), size,
TREE_CODE (tem) == SSA_NAME
? TYPE_ALIGN (TREE_TYPE (tem))
: get_object_alignment (tem));
As tem is a vector constant (not an SSA name), get_object_alignment (tem) is
used and returns an alignment of 8 bits (1 byte) only. As a result, the stack
slot is created with only 1-byte alignment, as the A8 (align 8-bits) appears in
above RTL dump.
Later, the subreg1 pass attempts to decompose the multiword store into pieces.
Each piece is in DImode, which requires 64-bit alignment. With
"-mstrict-align", the following condition in simplify_subreg()
!(STRICT_ALIGNMENT && MEM_ALIGN (op) < GET_MODE_ALIGNMENT (outermode))
is false, so simplify_subreg() returns NULL_RTX. However, it's treated as
impossible so the assert fails.
One possible fix could be to improve the alignment chosen for stack slots used
for constant vectors (e.g. using TYPE_ALIGN instead of get_object_alignment).
I'm not sure if this is a right direction so I'd like to hear your thoughts.
