https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98190
--- Comment #13 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 9 Dec 2020, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98190 > > --- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > (In reply to rsand...@gcc.gnu.org from comment #10) > > If we can't assert, I guess the rule is that we need to extend > > whenever we're storing to the MSB of the inner register. We can > > do that either by extending the source value and the range to > > the outer register, or by assigning to the inner register and > > then extending it separately. > > So perhaps: > --- gcc/expr.c.jj 2020-12-09 00:00:08.622548080 +0100 > +++ gcc/expr.c 2020-12-09 10:36:12.198801940 +0100 > @@ -5451,6 +5451,33 @@ expand_assignment (tree to, tree from, b > mode1, to_rtx, to, from, > reversep)) > result = NULL; > + else if (SUBREG_P (to_rtx) > + && SUBREG_PROMOTED_VAR_P (to_rtx)) > + { > + /* If to_rtx is a promoted subreg, this must be a store to the > + whole variable, otherwise to_rtx would need to be MEM. Yes, that's true - all !DECL_NOT_GIMPLE_REG_P may not have partial defs. > + We need to zero or sign extend the value afterwards. */ > + gcc_assert (known_eq (bitpos, 0) > + && known_eq (bitsize, > + GET_MODE_BITSIZE (GET_MODE (to_rtx)))); > + if (TREE_CODE (to) == MEM_REF && !REF_REVERSE_STORAGE_ORDER > (to)) > + result = store_expr (from, to_rtx, 0, nontemporal, false); > + else > + { > + result = store_field (to_rtx, bitsize, bitpos, > + bitregion_start, bitregion_end, > + mode1, from, get_alias_set (to), > + nontemporal, reversep); > + rtx to_rtx1 > + = lowpart_subreg (subreg_unpromoted_mode (to_rtx), > + SUBREG_REG (to_rtx), > + subreg_promoted_mode (to_rtx)); > + to_rtx1 = convert_to_mode (subreg_promoted_mode (to_rtx), > + to_rtx1, > + SUBREG_PROMOTED_SIGN (to_rtx)); > + emit_move_insn (SUBREG_REG (to_rtx), to_rtx1); > + } > + } > else > result = store_field (to_rtx, bitsize, bitpos, > bitregion_start, bitregion_end, > > then? As in, if store_expr can handle it, use that, otherwise perform the > extension at the end. > > As for BIT_INSERT_EXPR, I'm not sure if SSA_NAMEs can get promoted SUBREGs or > not, but in any case it wouldn't be this code path, it would be store_expr > which handles the promoted SUBREGs already, because destination would not be a > MEM_REF with non-mem decl or reversed order, nor handled_component_p, nor > ARRAY_TYPE destination. True.
