On Tue, Sep 03, 2019 at 02:49:01PM -0500, Segher Boessenkool wrote: > Hi! > > On Mon, Aug 26, 2019 at 05:20:12PM -0400, Michael Meissner wrote: > > @@ -3249,9 +3249,10 @@ (define_insn "vsx_vslo_<mode>" > > ;; Variable V2DI/V2DF extract > > (define_insn_and_split "vsx_extract_<mode>_var" > > [(set (match_operand:<VS_scalar> 0 "gpc_reg_operand" "=v,wa,r") > > - (unspec:<VS_scalar> [(match_operand:VSX_D 1 "input_operand" "v,m,m") > > - (match_operand:DI 2 "gpc_reg_operand" "r,r,r")] > > - UNSPEC_VSX_EXTRACT)) > > + (unspec:<VS_scalar> > > + [(match_operand:VSX_D 1 "reg_or_non_pcrel_operand" "v,ep,ep") > > + (match_operand:DI 2 "gpc_reg_operand" "r,r,r")] > > + UNSPEC_VSX_EXTRACT)) > > (clobber (match_scratch:DI 3 "=r,&b,&b")) > > (clobber (match_scratch:V2DI 4 "=&v,X,X"))] > > "VECTOR_MEM_VSX_P (<MODE>mode) && TARGET_DIRECT_MOVE_64BIT" > > After this patch, what happens if you have this instruction generated > with some pcrel memory? This pattern will no longer match. Or can that > not happen? Many places call gen_vsx_extract_*.
No, the only place that calls it directly is rs6000_expand_vector_extract. There are multiple references to gen_vsx_extract_<mode>_var because it has a switch statement to call the appropriate generator based on the mode. When rs6000_expand_vector_extract is called, it is in the expand phase of RTL, and a force_reg has been done to move the vector into a register. What this patch does is prevent the combiner from merging the load and extract in the one case where it is loading the value from a pc-relative address. In that case, the compiler will just load the vector into a register, and then do the normal variable extract from a register. > I wouldn't use "ep" for *non*-pcrel. The new constraints/predicates don't > need to do everything in a C block. Looks good otherwise. Any particular suggestions for the spelling? -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
