Hi Mike, On Thu, Sep 05, 2019 at 04:48:28PM -0400, Michael Meissner wrote: > On Tue, Sep 03, 2019 at 02:49:01PM -0500, Segher Boessenkool wrote: > > 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.
My grep found many more places because I plainly forgot the _var. Whoopsie. So no other places that use UNSPEC_VSX_EXTRACT can get pcrel addressing generated either, I guess. Okay. It's hard to ascertain this. > > 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? Not "p" because that suggests it *is* pcrel (or it is a pointer, perhaps). Maybe "en"? Most letters are still available, lots of choice :-) Segher
