This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, V3, #6 of 10], Fix vec_extract breakage
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: Michael Meissner <meissner at linux dot ibm dot com>, gcc-patches at gcc dot gnu dot org, dje dot gcc at gmail dot com
- Date: Thu, 5 Sep 2019 17:38:18 -0500
- Subject: Re: [PATCH, V3, #6 of 10], Fix vec_extract breakage
- References: <20190826173320.GA7958@ibm-toto.the-meissners.org> <20190826212012.GF11790@ibm-toto.the-meissners.org> <20190903194901.GD9749@gate.crashing.org> <20190905204828.GA29280@ibm-toto.the-meissners.org>
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