This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Wed, Feb 01, 2017 at 09:21:57AM +0100, Richard Biener wrote:
> it came with r173854 where you see other BOOLEAN_TYPE
> -> integral-type with precision 1 check changes, so a new predicate
> is very welcome IMHO.
> 
> all BOOLEAN_TYPEs but Adas have precision one and are unsigned
> (their TYPE_SIZE may vary though).  Adas larger precision boolean
> has only two valid values but needs to be able to encode some 'NaT'
> state.
> 
> I think BOOLEAN_COMPATIBLE_TYPE_P would be misleading as it isn't
> equal to types_compatible_p (boolean_type_node, t).
> 
> Maybe we want TWO_VALUED_UNSIGNED_INTEGRAL_TYPE_P ()? (ick)
> I thought "BOOLEAN" covers TWO_VALUED_UNSIGNED well enough but
> simply BOOLEAN_TYPE_P is easily confused with TREE_CODE () == 
> BOOLEAN_TYPE.
> 
> I'm fine with changing the predicate to be more explicit, like
> 
> #define INTEGRAL_BOOLEAN_TYPE_P(TYPE) \
>   (INTEGRAL_TYPE_P (TYPE) && TYPE_PRECISION (TYPE) == 1)
> 
> not sure if we really need the TYPE_UNSIGNED check?  The middle-end
> has various places that just check for a 1-precision type when
> asking for a boolean context.
> 
> So naming set aside, would you agree with the above definition?
> (modulo a && TYPE_UNSIGNED (TYPE))?

The TYPE_UNSIGNED check is there so that we don't consider signed 1 bit
bitfields as boolean, those are not compatible with any BOOLEAN_TYPE
(because they have different sign) and from the past experience, are
terribly hard to support properly ("true" is negative, is smaller than
"false", we had dozens of PRs about that kind of stuff already).

As for always checking TYPE_PRECISION == 1 and thus not considering
the Ada BOOLEAN_TYPE as something that should be vectorized as boolean
vector, I'm afraid (but haven't tried to prove that) it would make lots
of Ada testcases no longer vectorizable or vectorizable with much worse
code (especially on AVX512), and/or cause ICEs (if there are assumptions
e.g. that in COND_EXPR the first operand, if it is SSA_NAME, must be
vectorized as boolean vector type).

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]