> > I don't think this is correct.  Instead the use in the expander
> > should be adjusted as I wrote in the bugreport.  At least I do not see
> > that there's a guaranteee that the VECTOR_CST ends up in type aligned
> > memory if it is not asscoiated with an actual data object (STRING_CST
> > is indeed special here).
> 
> That said, get_object_alignment will return the maximum _guaranteed_
> alignment of an access.  The RTL expansion case needs to honor that,
> but as 1 byte is always a correct answer here, for STRICT_ALIGNMENT
> targets we probably need to to a MAX (GET_MODE_ALIGNMENT, ...) on it,
> or if BLKmode we might want to do MAX (TYPE_ALIGN, ...) on it.  Possibly
> that optional alignment need to be capped by max-stack alignment that
> can be used.

Thanks Richi for the suggestions.

This v2 patch increases the stack slot alignment in the expander and caps
it by MAX_SUPPORTED_STACK_ALIGNMENT, as Richi suggested.

This has been re-tested on aarch64-linux-gnu and x86_64-linux-gnu.

Thanks,
Pengfei

-- >8 --

PR123447 reports an ICE on AArch64 with "-O2 -mstrict-align" in subreg
lowering while decomposing the following multiword store RTL:

(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 RTL originates from expanding the following GIMPLE statement:

_1 = BIT_FIELD_REF <{ 9, -64497, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, 
256, 0>;

The operand is a constant _Decimal64 vector with BLKmode, so expand has
to materialize it in memory. Current get_object_alignment() returns a
1-byte guaranteed alignment for this VECTOR_CST, as indicated by A8 in
the RTL dump above. However, with "-mstrict-align" enabled, later subreg
lowering pass expects at least 64-bit alignment when it constructs a new
RTX to decompose the store into pieces. Because the original alignment
is too small, simplify_gen_subreg() returns NULL_RTX and an assertion is
hit.

This patch increases the stack slot alignment for STRICT_ALIGNMENT
targets, when the operand is forced into memory. The increased alignment
is capped by MAX_SUPPORTED_STACK_ALIGNMENT so it won't be too large.

Bootstrapped and tested on aarch64-linux-gnu and x86_64-linux-gnu.

gcc/ChangeLog:

        PR middle-end/123447
        * expr.cc (expand_expr_real_1): Increase stack slot alignment
        for STRICT_ALIGNMENT targets.

gcc/testsuite/ChangeLog:

        PR middle-end/123447
        * gcc.dg/pr123447.c: New test.
---
 gcc/expr.cc                     | 21 +++++++++++++++++----
 gcc/testsuite/gcc.dg/pr123447.c | 19 +++++++++++++++++++
 2 files changed, 36 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/pr123447.c

diff --git a/gcc/expr.cc b/gcc/expr.cc
index b6d593d09a2..d3dad6c8041 100644
--- a/gcc/expr.cc
+++ b/gcc/expr.cc
@@ -12336,13 +12336,26 @@ expand_expr_real_1 (tree exp, rtx target, 
machine_mode tmode,
           and need be, put it there.  */
        else if (CONSTANT_P (op0) || (!MEM_P (op0) && must_force_mem))
          {
+           machine_mode tem_mode = TYPE_MODE (TREE_TYPE (tem));
            poly_int64 size;
            if (!poly_int_tree_p (TYPE_SIZE_UNIT (TREE_TYPE (tem)), &size))
              size = max_int_size_in_bytes (TREE_TYPE (tem));
-           memloc = assign_stack_local (TYPE_MODE (TREE_TYPE (tem)), size,
-                                        TREE_CODE (tem) == SSA_NAME
-                                        ? TYPE_ALIGN (TREE_TYPE (tem))
-                                        : get_object_alignment (tem));
+           unsigned int align = TREE_CODE (tem) == SSA_NAME
+                                ? TYPE_ALIGN (TREE_TYPE (tem))
+                                : get_object_alignment (tem);
+           if (STRICT_ALIGNMENT)
+             {
+               /* For STRICT_ALIGNMENT targets, when we force the operand to
+                  memory, we may need to increase the alignment to meet the
+                  expectation in later RTL lowering passes.  The increased
+                  alignment is capped by MAX_SUPPORTED_STACK_ALIGNMENT.  */
+               if (tem_mode != BLKmode)
+                 align = MAX (align, GET_MODE_ALIGNMENT (tem_mode));
+               else
+                 align = MAX (align, TYPE_ALIGN (TREE_TYPE (tem)));
+               align = MIN (align, (unsigned) MAX_SUPPORTED_STACK_ALIGNMENT);
+             }
+           memloc = assign_stack_local (tem_mode, size, align);
            emit_move_insn (memloc, op0);
            op0 = memloc;
            clear_mem_expr = true;
diff --git a/gcc/testsuite/gcc.dg/pr123447.c b/gcc/testsuite/gcc.dg/pr123447.c
new file mode 100644
index 00000000000..b2ee1473758
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr123447.c
@@ -0,0 +1,19 @@
+/* PR middle-end/123447 */
+/* { dg-do compile { target aarch64*-*-* } } */
+/* { dg-options "-O2 -mstrict-align" } */
+
+typedef __attribute__((__vector_size__(32))) _Decimal64 D;
+typedef __attribute__((__vector_size__(64))) int V;
+typedef __attribute__((__vector_size__(64))) _Decimal64 D64;
+
+D d;
+
+void foo1 () {
+  D _4;
+  D64 _5;
+  V _1;
+  _1 = (V) { 9, -64497, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
+  _5 = (D64) _1;
+  _4 = __builtin_shufflevector (_5, _5, 0, 1, 2, 3);
+  d = _4;
+}
-- 
2.43.0

Reply via email to