On Thu, Jan 18, 2024 at 08:27:51AM +0100, Richard Biener wrote:
> On Thu, 18 Jan 2024, Jakub Jelinek wrote:
>
> > Hi!
> >
> > On aarch64 the backend decides to use non-BLKmode for some arrays
> > like unsigned long[4] - OImode in that case, but the corresponding
> > BITINT_TYPEs have BLKmode (like structures containing that many limb
> > elements). This both isn't a good idea (we really want such underlying vars
> > to live in memory and access them there, rather than live in registers and
> > access their parts in there) and causes ICEs during expansion
> > (VIEW_CONVERT_EXPR from such OImode array to BLKmode BITINT_TYPE), so the
> > following patch makes sure such arrays reflect the BLKmode of BITINT_TYPEs
> > it is accessed with (if any).
> >
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> So the issue is only manifesting during expansion? I think it would
> be better to detect the specific issue (V_C_E from register to BLKmode)
> in discover_nonconstant_array_refs_r and force the register argument
> to stack?
That doesn't really work, tried:
--- gcc/cfgexpand.cc.jj 2024-01-16 11:45:16.159326506 +0100
+++ gcc/cfgexpand.cc 2024-01-18 11:26:17.906447274 +0100
@@ -6380,11 +6380,16 @@ discover_nonconstant_array_refs_r (tree
/* References of size POLY_INT_CST to a fixed-size object must go
through memory. It's more efficient to force that here than
to create temporary slots on the fly.
- RTL expansion expectes TARGET_MEM_REF to always address actual memory. */
+ RTL expansion expectes TARGET_MEM_REF to always address actual memory.
+ Also, force to stack non-BLKmode vars accessed through VIEW_CONVERT_EXPR
+ to BLKmode BITINT_TYPEs. */
else if (TREE_CODE (t) == TARGET_MEM_REF
|| (TREE_CODE (t) == MEM_REF
&& TYPE_SIZE (TREE_TYPE (t))
- && POLY_INT_CST_P (TYPE_SIZE (TREE_TYPE (t)))))
+ && POLY_INT_CST_P (TYPE_SIZE (TREE_TYPE (t))))
+ || (TREE_CODE (t) == VIEW_CONVERT_EXPR
+ && TREE_CODE (TREE_TYPE (t)) == BITINT_TYPE
+ && TYPE_MODE (TREE_TYPE (t)) == BLKmode))
{
tree base = get_base_address (t);
if (base
This doesn't actually do anything, because the base is TREE_ADDRESSABLE.
The var gets both with -O0 and -O2 DECL_RTL like
(mem/c:OI (plus:DI (reg/f:DI 95 virtual-stack-vars)
(const_int -64 [0xffffffffffffffc0])) [2 bitint.2+0 S32 A128])
but the problem is that the expansion of the VAR_DECL because of the
non-BLKmode is forced into a pseudo.
--- gcc/expr.cc.jj 2024-01-12 10:07:58.194851657 +0100
+++ gcc/expr.cc 2024-01-18 11:56:07.142361031 +0100
@@ -12382,6 +12382,17 @@ expand_expr_real_1 (tree exp, rtx target
}
}
+ /* Ensure non-BLKmode array VAR_DECLs VCEd to BLKmode BITINT_TYPE
+ aren't promoted to registers. */
+ if (op0 == NULL_RTX
+ && mode == BLKmode
+ && TREE_CODE (type) == BITINT_TYPE
+ && modifier == EXPAND_NORMAL
+ && VAR_P (treeop0)
+ && DECL_MODE (treeop0) != BLKmode)
+ op0 = expand_expr_real (treeop0, NULL_RTX, VOIDmode, EXPAND_MEMORY,
+ NULL, inner_reference_p);
+
if (!op0)
op0 = expand_expr_real (treeop0, NULL_RTX, VOIDmode, modifier,
NULL, inner_reference_p);
doesn't work either, while we get the MEM op0 in that case, because
mode != GET_MODE (op0) we still take the
/* If the output type is a bit-field type, do an extraction. */
else if (reduce_bit_field)
return extract_bit_field (op0, TYPE_PRECISION (type), 0,
TYPE_UNSIGNED (type), NULL_RTX,
mode, mode, false, NULL);
path which can't deal with BLKmode extraction from non-BLKmode.
I guess we could in the above new expr.cc hunk perhaps
also if (MEM_P (op0)) op0 = adjust_address (op0, BLKmode, 0);
Jakub
