Re: [PATCH, x86] Generate vector -1 with pcmpeq

[Evan Cheng <evan dot cheng at apple dot com>]

Oops. Missed a file. One more try:

Attachment: patch.fsf.4283414.txt
Description: Text document

Evan

On Nov 2, 2005, at 2:30 PM, Evan Cheng wrote:

> Here is a new patch:
>
>
> <patch.fsf.4283414.txt>
>
> Thanks,
>
> Evan
>
> On Nov 1, 2005, at 1:09 PM, Richard Henderson wrote:
>
>
> > On Fri, Oct 28, 2005 at 01:10:18PM -0700, Evan Cheng wrote:
> >
> >
> > > + /* Return true if the rtx is a vector constant that is all  
> > > ones.  */
> > > + bool
> > > + ix86_const_vector_all_ones_operand (rtx v, enum machine_mode mode)
> >
> > There's no reason to have this code outside predicates.md.
> >
> >
> >
> > > +           if (GET_CODE (x) != CONST_INT || INTVAL (x) != -1)
> >
> > x != constm1_rtx.
> >
> > You could probably also match the corresponding NaN, but
> > perhaps it's not worth it.
> >
> >
> >
> > > !     case 2:
> > > !       if (get_attr_mode (insn) == MODE_V2DF)
> > > !         return "pcmpeqd\t%0, %0";
> > > !       else
> > > !         return "pcmpeqw\t%0, %0";
> >
> > Which brings me to this distinction.  What are you doing?  If you
> > really need this in V2DFmode you'd be using cmpneqpd.  But that
> > would imply you'd been matching a vector of nan("0xff...") and you
> > aren't.
> >
> > I don't see that any processor distinguishes between integer modes,
> > so I don't see any reason not to always use pcmpeqd, or always
> > pcmpeqw, or for that matter pcmpeqb.
> >
> > Which raises the question of SSE1, which I'll get back to.
> >
> >
> >
> > > !  abort ();
> >
> > gcc_unreachable.
> >
> >
> >
> > > +       && !ix86_const_vector_all_ones_operand (op1, mode)
> > >         && CONSTANT_P (op1) && op1 != CONST0_RTX (mode))
> >
> > Use standard_sse_constant_p here.
> >
> >
> >
> > > !   "TARGET_SSE && ix86_binary_operator_ok (UNKNOWN, V4SFmode,  
> > > operands)"
> > ...
> >
> >
> > > !   "TARGET_SSE && ix86_binary_operator_ok (UNKNOWN, V4SFmode,  
> > > operands)
> > > !    && !ix86_const_vector_all_ones_operand (operands[2], V4SFmode)"
> >
> > I'm guessing this is locally adjusting for vector_move_operand.
> > Notice how you had to replicate this 8 times.  Better to fix this
> > once elsewhere.
> >
> > My thinking is that standard_sse_constant_p should return false
> > for -1 on SSE1, and that vector_move_operand should use
> > standard_sse_constant_p instead of listing out the alternatives.
> >
> >
> > r~