On Wed, Feb 01, 2017 at 10:58:29AM +0100, Richard Biener wrote:
> > > +/* Nonzero if TYPE represents a (scalar) boolean type or type
> > > + in the middle-end compatible with it. */
> > > +
> > > +#define INTEGRAL_BOOLEAN_TYPE_P(TYPE) \
> > > + (TREE_CODE (TYPE) == BOOLEAN_TYPE \
> > > + || ((TREE_CODE (TYPE) == INTEGER_TYPE \
> > > + || TREE_CODE (TYPE) == ENUMERAL_TYPE) \
> > > + && TYPE_PRECISION (TYPE) == 1 \
> > > + && TYPE_UNSIGNED (TYPE)))
> > >
> > > (just to quote what you proposed).
> >
> > So would it help to use
> > (TREE_CODE (TYPE) == BOOLEAN_TYPE
> > || (INTEGRAL_TYPE_P (TYPE)
> > && useless_type_conversion_p (boolean_type_node, TYPE)))
> > It would be much slower than the above, but would be less dependent
> > on useless_type_conversion_p details.
>
> For the vectorizer it likely would break the larger logical type
> handling?
Why? It is the same thing as the earlier macro above.
Any kind of boolean, plus anything that could be initially boolean
and the middle-end might have replaced it with.
> The question is really what the vectorizer and other places are looking
> for -- which isually is a 1-bit precision, eventually unsigned,
> integral type.
It is looking for any type where the only valid values are 0 (false) and 1
(true), so that it can actually vectorize it as a bitmask, or vector of
integers with -1 and 0 values.
Jakub
