On Wed, Jul 29, 2015 at 06:38:45PM -0400, Michael Meissner wrote:
> On Wed, Jul 29, 2015 at 04:59:23PM -0500, Segher Boessenkool wrote:
> > On Wed, Jul 29, 2015 at 04:04:28PM -0400, Michael Meissner wrote:
> > > +;; Return constant 0x80000000000000000000000000000000 in an Altivec 
> > > register.
> > > +
> > > +(define_expand "altivec_high_bit"
> > > +  [(set (match_dup 1)
> > > + (vec_duplicate:V16QI (const_int 7)))
> > > +   (set (match_dup 2)
> > > + (ashift:V16QI (match_dup 1)
> > > +               (match_dup 1)))
> > > +   (set (match_dup 3)
> > > + (match_dup 4))
> > > +   (set (match_operand:V16QI 0 "register_operand" "")
> > > + (unspec:V16QI [(match_dup 2)
> > > +                (match_dup 3)
> > > +                (const_int 15)] UNSPEC_VSLDOI))]
> > > +  "TARGET_ALTIVEC"
> > > +{
> > > +  if (can_create_pseudo_p ())
> > > +    {
> > > +      operands[1] = gen_reg_rtx (V16QImode);
> > > +      operands[2] = gen_reg_rtx (V16QImode);
> > > +      operands[3] = gen_reg_rtx (V16QImode);
> > > +    }
> > > +  else
> > > +    operands[1] = operands[2] = operands[3] = operands[0];
> > 
> > This won't work (in the pattern you write to op 3 before reading from op 2).
> > Do you ever call this expander late, anyway?
> 
> I'm not sure I follow you.

I'm sorry, I meant that very last line I quoted, the !can_create_pseudo_p ()
one.  If that is executed operands[2] will be the same reg as operands[3],
and things fall apart.


Segher

Reply via email to