acsaw...@linux.ibm.com writes: > From: Aaron Sawdey <acsaw...@linux.ibm.com> > > After discussion with Richard Sandiford on IRC, he suggested adding a > new mode class MODE_OPAQUE to deal with the problems (PR 96791) we had > been having with POImode/PXImode in powerpc target. This patch is the > accumulation of changes I needed to make to add this and make it useable > for the purposes of what power10 MMA needed. > > MODE_OPAQUE modes allow you to have modes for which you can just > define loads and stores. By design, optimization does not expect to > know how to do arithmetic or subregs on these modes. This allows us to > have modes for multi-register vector operations where we don't want to > open Pandora's Box and define general arithmetic operations. > > This patch will be followed by a target specific patch to change the > powerpc power10 MMA builtins to use opaque modes, and will also let use use > the vector pair loads/stores defined with that in the inline expansion > of memcpy/memmove, allowing me to fix PR 96791. > > Regstrap in progress on ppc64le and x86_64, ok for trunk if successful?
Thanks for doing this. Mostly LGTM, but: > diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c > index 3706f0a03fd..44a3b660bd0 100644 > --- a/gcc/emit-rtl.c > +++ b/gcc/emit-rtl.c > @@ -6268,6 +6268,9 @@ init_emit_once (void) > mode <= MAX_MODE_PARTIAL_INT; > mode = (machine_mode)((int)(mode) + 1)) > const_tiny_rtx[i][(int) mode] = GEN_INT (i); > + > + FOR_EACH_MODE_IN_CLASS (mode, MODE_OPAQUE) > + const_tiny_rtx[i][(int) mode] = GEN_INT (i); I'm not sure about reusing CONST_INT & co. for something that isn't a scalar_int_mode. The only reason routines like trunc_int_for_mode allow general scalar_modes is that, when the new mode wrappers were added, (const_int 0) was used for the MPX pointer bounds modes. We should probably go back and tighten it now that MPX has been removed. So I guess the question is: how integer-like do the modes need to be? Do we need to be able to represent any constant bitpattern as a constant rtx? If we do need to be able to represent any value as a constant, does treating opaque modes as SCALAR_INT_MODE_P reintroduce the original problem? If not, I think doing that would make things more self-consistent. If we don't need to be able to represent any value as a constant, which values do we need? Is all-zeroes enough? If so, maybe it would be better to have a new CONST_… rtx code. > diff --git a/gcc/ira.c b/gcc/ira.c > index 050405f1833..d7a0482d121 100644 > --- a/gcc/ira.c > +++ b/gcc/ira.c > @@ -4666,7 +4666,8 @@ find_moveable_pseudos (void) > || !DF_REF_INSN_INFO (def) > || HARD_REGISTER_NUM_P (regno) > || DF_REG_EQ_USE_COUNT (regno) > 0 > - || (!INTEGRAL_MODE_P (mode) && !FLOAT_MODE_P (mode))) > + || (!INTEGRAL_MODE_P (mode) && !FLOAT_MODE_P (mode) > + && !OPAQUE_MODE_P (mode))) Nit: should be one && per line now that it doesn't fit on a single line. > diff --git a/gcc/tree-ssanames.c b/gcc/tree-ssanames.c > index 6ac97fe39c4..1fb21635a3b 100644 > --- a/gcc/tree-ssanames.c > +++ b/gcc/tree-ssanames.c > @@ -516,6 +516,9 @@ get_nonzero_bits (const_tree name) > if (TREE_CODE (name) == INTEGER_CST) > return wi::to_wide (name); > > + if (OPAQUE_TYPE_P (TREE_TYPE (name))) > + return wi::shwi (-1, 1); > + > /* Use element_precision instead of TYPE_PRECISION so complex and > vector types get a non-zero precision. */ > unsigned int precision = element_precision (TREE_TYPE (name)); Using a precision of 1 looks odd here. What goes wrong if we use the precision calculated by element_precision? Does OPAQUE_TYPE have a valid TYPE_PRECISION (equal to the mode's GET_MODE_BITSIZE)? If not, I guess it probably should. The new type needs to be documented in doc/generic.texi. Thanks, Richard
