http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845
--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 4 Nov 2013, glisse at gcc dot gnu.org wrote: > 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. Thus no short-circuiting for vector && or ||. > 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. Yeah, exactly. Still if there is a sequence point at && or || (even if both arms are always executed) then the order of evaluating side-effects is important. IIRC only AND/ORIF have an implicit sequence point during gimplification. > (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? No short-circuiting but preserving the sequence point (if there is one)
