On Thu, 18 Jan 2024, Jakub Jelinek wrote: > On Thu, Jan 18, 2024 at 01:34:53PM +0100, Richard Biener wrote: > > So - if we simply do > > > > /* If the input and output modes are both the same, we are done. */ > > if (mode == GET_MODE (op0) || (mode == BLKmode && MEM_P (op0)) > > ; > > > > ? After all if we want BLKmode we want a MEM, and if we have one > > we should be done already. V_C_E isn't supposed to do any value > > transform. > > We'd need to make sure that op0 is actually MEM, which is not the case. > > The following patch seems to work though, the > discover_nonconstant_array_refs_r > part helps for -O2, the expr.cc part is needed at all optimization levels. > > 2024-01-18 Jakub Jelinek <ja...@redhat.com> > > * cfgexpand.cc (discover_nonconstant_array_refs_r): Force non-BLKmode > VAR_DECLs referenced in BLKmode VIEW_CONVERT_EXPRs into memory. > * expr.cc (expand_expr_real_1) <case VIEW_CONVERT_EXPR>: If mode is > BLKmode and type a BITINT_TYPE from a non-BLKmode VAR_P with MEM > DECL_RTL, use adjust_address to BLKmode for it instead of expand_expr. > > --- gcc/cfgexpand.cc.jj 2024-01-16 11:45:16.159326506 +0100 > +++ gcc/cfgexpand.cc 2024-01-18 13:41:54.579551282 +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))
I'm still not getting what's special about BITINT_TYPE here so shouldn't that apply to all BLKmode V_C_E? But sure we can for now just handle BITINT_TYPE. That hunk looks OK to me. > { > tree base = get_base_address (t); > if (base > --- gcc/expr.cc.jj 2024-01-12 10:07:58.194851657 +0100 > +++ gcc/expr.cc 2024-01-18 13:38:19.677556646 +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 > + && VAR_P (treeop0) > + && DECL_MODE (treeop0) != BLKmode > + && DECL_RTL_SET_P (treeop0) > + && MEM_P (DECL_RTL (treeop0))) > + op0 = adjust_address (DECL_RTL (treeop0), BLKmode, 0); > + > if (!op0) > op0 = expand_expr_real (treeop0, NULL_RTX, VOIDmode, modifier, > NULL, inner_reference_p); So we're now sure we have MEM_P (op0) after expand_expr_real, even without this change, right? What's wrong with the suggestion to use if (mode == GET_MODE (op0) || (mode == BLKmode && MEM_P (op0)) thus not run into any of the special-casing? We're doing just op0 = adjust_address (op0, mode, 0); then which is basically what you do above? > > Jakub > > -- Richard Biener <rguent...@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)