On Mon, Jun 27, 2016 at 09:54:09AM -0500, Pat Haugen wrote:
> On 06/22/2016 02:10 PM, Segher Boessenkool wrote:
> > The "power9_alu2" attribute is writing part of the scheduling description
> > inside the machine description proper. Can this be reduced, maybe by
> > adding an attribute describing something about the insns that makes them
> > be handled by the alu2? I realise it isn't all so regular :-(
>
>
> >> > +; 2 cycle FP ops
> >> > +(define_attr "power9_fp_2cyc" "no,yes"
> >> > + (cond [(eq_attr "mnemonic" "fabs,fcpsgn,fmr,fmrgow,fnabs,fneg,\
> >> > + xsabsdp,xscpsgndp,xsnabsdp,xsnegdp,\
> >> > + xsabsqp,xscpsgnqp,xsnabsqp,xsnegqp")
> >> > + (const_string "yes")]
> >> > + (const_string "no")))
> > Eww. Can we have an attribute for the FP move instructions, instead?
> > Maybe a value "fpmove" for the "type", even?
>
> The following patch adds new insn 'type' values that will be used for the
> Power9 patch to overcome the items listed above. There is no functional
> change to existing processor types. Bootstrap/regtested on
> powerpc64/powerpc64le with no new failures. Ok for trunk? Ok for backport to
> GCC 6 branch after successful bootstrap/regtest there?
Hi Pat,
> * config/rs6000/rs6000.md ('type' attribute): Add
> vec_logical,veccmp_fx,vec_extend,vecmove insn types.
Those names are a bit irregular (underscore vs. no underscore after "vec",
"extend" is called "exts" for integer, "vec_logical" holds no relation to
integer "logical").
That said... If this makes the power9 scheduling patch better, okay
for trunk and 6 later. So please wait for a review of that patch.
Thanks,
Segher
