On Mon, Mar 28, 2022 at 06:30:41PM -0400, Michael Meissner wrote: > On Mon, Mar 28, 2022 at 12:14:09PM -0500, Segher Boessenkool wrote: > > On Mon, Mar 28, 2022 at 12:26:02PM -0400, Michael Meissner wrote: > > > However on power9 and power10 it generates: > > > > > > ;; vec_splats (vec_extract (src, 0)) > > > mfvsld 3,34 > > > mtvsrdd 34,9,9 > > > > > > ;; vec_splats (vec_extract (src, 1)) > > > mfvsrd 9,34 > > > mtvsrdd 34,9,9 > > > > > > This is due to the power9 having the mfvsrld instruction which can extract > > > either 64-bit element into a GPR. While there are alternatives for both > > > vector registers and GPR registers, the register allocator prefers to put > > > DImode into GPR registers. > > > > As I said in comment 2 in the PR, it is because we do not have this > > pattern yet, we only have vec_concat. The instruction combiner tries > > to use this pattern, but it doesn't exist :-) > > Ok. I will create that function and see if it works.
That is what this patch *does*! *That* needs to be in the commit message! > > > + if (!BYTES_BIG_ENDIAN) > > > + which_word = 1 - which_word; > > > + > > > + operands[3] = GEN_INT (which_word ? 3 : 0); > > > + return "xxpermdi %x0,%x1,%x1,%3"; > > > > Please use gen_vsx_xxspltd_v2di, instead. Which itself should not use > > an unspec of course, but that is another patch. > > There is also vsx_concat_<mode>_3 which does not use an UNSPEC. Maybe > eventually rewrite vsx_xxspltd_v2di to be a define_insn_and_split. It almost always is a bad idea to have a 1->1 split: you are rewriting the canonical way to write something to something non-canonical. (Where "canonical" means "actually canonical, and/or what GCC generates anyway"). It doesn't save anything over an extra define_insn either, anyway? Segher
