[PATCH] Fix bool vs. unsigned:1 vectorization (PR tree-optimization/79284)

Richard Biener rguenther@suse.de
Wed Feb 1 10:07:00 GMT 2017


On Wed, 1 Feb 2017, Jakub Jelinek wrote:

> 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.

boolean_type_node is QImode but logical(8) is DImode for example.
Both have precision == 1 but they are not types_compatible_p
(you probably missed the mode check in useless_type_conversion_p).

> > 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.

That's INTEGRAL_TYPE_P && TYPE_PRECISION == 1 && TYPE_UNSIGNED.  The
Ada types do not fall under this category as far as I understand as
the exceptional values may exist in memory(?)

Richard.



More information about the Gcc-patches mailing list