Re: Remove redundant AND from count reduction loop

[Marc Glisse <marc dot glisse at inria dot fr>]

On Wed, 24 Jun 2015, Richard Biener wrote:

> On Wed, Jun 24, 2015 at 11:57 AM, Richard Sandiford
> <richard.sandiford@arm.com> wrote:
> > Richard Biener <richard.guenther@gmail.com> writes:
> > > On Tue, Jun 23, 2015 at 11:27 PM, Marc Glisse <marc.glisse@inria.fr> wrote:
> > > > On Tue, 23 Jun 2015, Richard Sandiford wrote:
> > > >
> > > > > +/* Vector comparisons are defined to produce all-one or all-zero results.
> > > > > */
> > > > > +(simplify
> > > > > + (vec_cond @0 integer_all_onesp@1 integer_zerop@2)
> > > > > + (if (tree_nop_conversion_p (type, TREE_TYPE (@0)))
> > > > > +   (convert @0)))
> > > >
> > > >
> > > > I am trying to understand why the test tree_nop_conversion_p is the right
> > > > one (at least for the transformations not using VIEW_CONVERT_EXPR). By
> > > > definition of VEC_COND_EXPR, type and TREE_TYPE (@0) are both integer vector
> > > > types of the same size and number of elements. It thus seems like a
> > > > conversion is always fine. For vectors, tree_nop_conversion_p apparently
> > > > only checks that they have the same mode (quite often VOIDmode I guess).
> > >
> > > The only conversion we seem to allow is changing the signed vector from
> > > the comparison result to an unsigned vector (same number of elements
> > > and same mode of the elements).  That is, a check using
> > > TYPE_MODE (type) == TYPE_MODE (TREE_TYPE (@0)) would probably
> > > be better (well, technically a TYPE_VECTOR_SUBPARTS && element
> > > mode compare should be better as generic vectors might not have a vector mode).
> >
> > OK.  The reason I was being paranoid was that I couldn't see anywhere
> > where we enforced that the vector condition in a VEC_COND had to have
> > the same element width as the values being selected.
>
> We don't require that indeed.
>
> >  tree-cfg.c
> > only checks that rhs2 and rhs3 are compatible with the result.
> > There doesn't seem to be any checking of rhs1 vs. the other types.
> > So I wasn't sure whether anything stopped us from, e.g., comparing two
> > V4HIs and using the result to select between two V4SIs.
>
> Nothing does (or should).

The documentation patch you approved in 
https://gcc.gnu.org/ml/gcc-patches/2012-10/msg01109.html says something 
different. If it is really wrong, could you fix it?

--
Marc Glisse