On Mon, Mar 28, 2022 at 03:28:39PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Mar 28, 2022 at 12:27:05PM -0400, Michael Meissner wrote:
> > In looking at PR target/99293, I noticed that the code in the insn
> > vsx_splat_<mode>_reg used "vecmove" as the "type" insn attribute when the
> > "mtvsrdd" is generated. It should use "mfvsr". I also added a "p9v" isa
> > attribute for that alternative.
>
> s/mfvsr/mtvsr/
>
> But, mtvsrd and mtvsrdd have very different scheduling properties (like,
> on p10 it is 1 cycle vs. 3 cycles).
I must admit, I assumed vecmove was a stand-in for XXMR (i.e. XXLOR). Since
its use is used for other cases (mtvsrdd, xxsel/vsel, x{s,v}abs*, x{s,v}nabs*,
xsiexpq*), it is probably better to just let things lie, and perhaps relook at
it in the GCC 13 time frame.
> Also, there are two insn patterns for mtvsrdd, and you are only touching
> one here.
I think you meant that comment about the third patch (to vsx_extract_<mode>)
and not to this patch (to vsx_splat_<mode>_reg) where there are only two
alternatives (the first being xxpermdi and the second being mtvsrdd).
> > * config/rs6000/rs6000.md (vsx_splat_<mode>_reg): Use the correct
> > insn type attribute. Add "p9v" isa attribute for generating the
> > mtvsrdd instruction.
>
> This is in vsx.md, instead.
>
> > --- a/gcc/config/rs6000/vsx.md
> > +++ b/gcc/config/rs6000/vsx.md
> > @@ -4580,7 +4580,8 @@ (define_insn "vsx_splat_<mode>_reg"
> > "@
> > xxpermdi %x0,%x1,%x1,0
> > mtvsrdd %x0,%1,%1"
> > - [(set_attr "type" "vecperm,vecmove")])
> > + [(set_attr "type" "vecperm,mtvsr")
> > + (set_attr "isa" "*,p9v")])
>
> "we" requires "p9v". Please do a full conversion when getting rid of
> this? That includes requiring TARGET_POWERPC64 for it (not -m64 as its
> documentation says; the existing implementation of "we" is correct).
That is more complex, and likely it should be a GCC 13 thing. Off the top of
my head, we would need a new "isa" variant (p9v64) that combines p9v and
64-bit. Originally, I had changed the "we" to "wa", but then I realized it
wouldn't work for 32-bit, but I left in setting the alternative.
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
