http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845
--- Comment #8 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #5)
> Well, what does OpenCL specify here?
"The logical operators and (&&), or (||) operate on all scalar and vector
built-in types. For scalar built-in types only, and (&&) will only evaluate
the right hand operand if the left hand operand compares unequal to 0. For
scalar built-in types only, or (||) will only evaluate the right hand operand
if the left hand operand compares equal to 0. For built-in vector types, both
operands are evaluated and the operators are applied component-wise. If one
operand is a scalar and the other is a vector, the scalar may be subject to the
usual arithmetic conversion to the element type used by the vector operand. The
scalar type is then widened to a vector that has the same number of components
as the vector operand. The operation is done component-wise resulting in the
same size vector.
The logical operator exclusive or (^^) is reserved.
The result is a scalar signed integer of type int if the source operands are
scalar and a vector signed integer type of the same size as the source operands
if the source operands are vector types. Vector source operands of type charn
and ucharn return a charn result; vector source operands of type shortn and
ushortn return a shortn result; vector source operands of type intn, uintn and
floatn return an intn result; vector source operands of type longn, ulongn and
doublen return a longn result.
For scalar types, the logical operators shall return 0 if the result of the
operation is false and 1 if the result is true. For vector types, the logical
operators shall return 0 if the result of the operation is false and -1 (i.e.
all bits set) if the result is true."
> v1 && v2
>
> should be emitted as GENERIC
>
> (v1 != { 0, 0, ... }) && (v2 != { 0, 0, ... })
>
> where the ANDIF semantics don't make sense for vectors(?) and thus we
> can directly emit GENERIC
>
> (v1 != { 0, 0, ... }) & (v2 != { 0, 0, ... })
>
> from the frontend.
IIRC that's what the patch did:
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00783.html
(In reply to Jakub Jelinek from comment #6)
> If there are no side-effects in v1 or v2, why not, but if there are
> side-effects, IMHO it should act as ANDIF, not as BIT_AND_EXPR.
What does ANDIF mean in this case? Only evaluate v2 if v1 has at least one
non-zero element? That still doesn't match the scalar version. Only evaluate
parts of v2? That doesn't seem possible.
(In reply to rguent...@suse.de from comment #7)
> Then I'd say leave the whole thing to gimplification.
And implement what semantics in gimplification?
