[ExtVector] Support ExtVectorType conditional operator

[myhsu]

Summary

Extension vectors now can be used in element-wise conditional selector.
For example:

R[i] = C[i]? A[i] : B[i]

This feature was previously only enabled in OpenCL C. Now it's also
available in C. Not that it has different behaviors than GNU vectors
(i.e. vector_size). Extension vectors selects on signdness of the
vector. GNU vectors on the other hand do normal bool conversions. Also,
this feature is not available in C++.

[Anastasia]

clang/docs/LanguageExtensions.rst

481

I think it was more clear as a footnote though.

489

has different behaviors depends on -> has different behaviors depending on

493

Maybe we can add a reference to OpenCL C section 6.3.9

clang/lib/Sema/SemaExpr.cpp

7616

Why do you need this change? I believe OpenCL makes the same restriction.

8104

Do you know where it is done for OpenCL? I think we should try to share the same code...

[myhsu]

clang/lib/Sema/SemaExpr.cpp

7616

I'm not quite sure what restriction you're referring here. If you're saying OpenCL only allow ext_vector_type on condition operand, I don't think that's the case since on line 7956 ~ 7957 of Sema/SemaExpr.cpp :

if (getLangOpts().OpenCL && Cond.get()->getType()->isVectorType())
    return OpenCLCheckVectorConditional(*this, Cond, LHS, RHS, QuestionLoc);

isVectorType() will be true for both GNU vector and ext_vector_type.

Regarding why i add the change here rather than merging with OpenCL's flow (which is related to another comments below), OpenCL's flow diverge into line 7957, as shown above, pretty early in the entire checking flow. And OpenCLCheckVectorConditional do other additional works. Most notably, promoting all scalar operands into vector if condition is a vector. I'm not sure if we should bring this feature to ext_vector

8104

It's inside OpenCLCheckVectorConditional function. As I mentioned in earlier comment, as long as we agree to bring every OpenCL features/rules regarding conditional vectors to ext_vector_type, I'm happy to reuse OpenCLCheckVectorConditional

[myhsu]

Fix document section

[Anastasia]

clang/lib/Sema/SemaExpr.cpp

7616

I'm not quite sure what restriction you're referring here.

You are restricting the use non-integer vectors in condition, is it not?

I'm not sure if we should bring this feature to ext_vector.

So what is it that you are trying to implement? My initial understanding was that you are just enabling behavior from OpenCL vectors to work in non-OpenCL mode. But you need to deviate from it?

8104

I don't know... I have no preference tbh. I think following OpenCL rules might be simpler from implementation and documentation perspective. But is it what you need?

[myhsu]

clang/lib/Sema/SemaExpr.cpp

7616

My initial understanding was that you are just enabling behavior from OpenCL vectors to work in non-OpenCL mode

My initial thoughts was to bring, and only bring, OpenCL-style condition operands to ext_vector. Since that's the key to enable some hardware accelerations like the Intel AVX example I put in the original proposal.

But maybe I'm too cautious about introducing other OpenCL vector properties to ext_vector. After crafting some test cases, I found that there is little to no impact on simply using full set of OpenCL vector's semantic rules. So I'll update this patch to unify the checks between OpenCL vectors and ext_vector.

[myhsu]

Use full set of OpenCL semantic rules for ext_vector_type

[Anastasia]

LGTM! Thanks! Please address small documentation nitpick before committing...

Btw does your change fix this bug:
https://bugs.llvm.org/show_bug.cgi?id=33103

clang/docs/LanguageExtensions.rst

496

s6.3.i -> s6.3.9

[myhsu]

Thank you @Anastasia !

[myhsu]

Btw does your change fix this bug:
https://bugs.llvm.org/show_bug.cgi?id=33103

As mentioned in the description, this patch only affect C code not C++ code. So strictly speaking this patch doesn't fix the bug, but if the same code attached in the bug report is compiled as C code it will pass.

clang/docs/LanguageExtensions.rst

 unary operators +, --            yes     yes       yes         --
 ++, -- --                        yes     yes       yes         --
 +,--,*,/,%                       yes     yes       yes         --
 bitwise operators &,|,^,~        yes     yes       yes         --
 >>,<<                            yes     yes       yes         --
 !, &&, ||                        yes     --        yes [#]_    --
 ==, !=, >, <, >=, <=             yes     yes       yes         --
 =                                yes     yes       yes         yes
-:? [#]_                          yes     --        yes         --
+?: [#]_                          yes     --        yes         --
 sizeof                           yes     yes       yes         yes
 C-style cast                     yes     yes       yes         no
 reinterpret_cast                 yes     no        yes         no
 static_cast                      yes     no        yes         no
 const_cast                       no      no        no          no
 ============================== ======= ======= ============= =======
 
 See also :ref:`langext-__builtin_shufflevector`, :ref:`langext-__builtin_convertvector`.
 
 .. [#] unary operator ! is not implemented, however && and || are.
-.. [#] While OpenCL and GCC vectors both implement the comparison operator(?:) as a
-  'select', they operate somewhat differently. OpenCL selects based on signedness of
-  the condition operands, but GCC vectors use normal bool conversions (that is, != 0).
+.. [#] ternary operator(?:) has different behaviors depending on condition
+  operand's vector type. If the condition is a GNU vector (i.e. __vector_size__),
+  it's only available in C++ and uses normal bool conversions (that is, != 0).
+  If it's an extension (OpenCL) vector, it's only available in C and OpenCL C.
+  And it selects base on signedness of the condition operands (OpenCL v1.1 s6.3.9).
 
 Matrix Types
 ============
 
 Clang provides an extension for matrix types, which is currently being
 implemented. See :ref:`the draft specification <matrixtypes>` for more details.
 
 For example, the code below uses the matrix types extension to multiply two 4x4

clang/lib/CodeGen/CGExprScalar.cpp

if (!CGF.ContainsLabel(dead)) {
         Result = llvm::UndefValue::get(CGF.ConvertType(E->getType()));
 
       return Result;
     }
   }
 
   // OpenCL: If the condition is a vector, we can treat this condition like
   // the select function.
-  if (CGF.getLangOpts().OpenCL
-      && condExpr->getType()->isVectorType()) {
+  if ((CGF.getLangOpts().OpenCL && condExpr->getType()->isVectorType()) ||
+      condExpr->getType()->isExtVectorType()) {
     CGF.incrementProfileCounter(E);
 
     llvm::Value *CondV = CGF.EmitScalarExpr(condExpr);
     llvm::Value *LHS = Visit(lhsExpr);
     llvm::Value *RHS = Visit(rhsExpr);
 
     llvm::Type *condType = ConvertType(condExpr->getType());
     llvm::VectorType *vecTy = cast<llvm::VectorType>(condType);

clang/lib/Sema/SemaExpr.cpp

S.Diag(QuestionLoc, diag::err_typecheck_cond_expect_nonfloat)
       << CondTy << Cond->getSourceRange();
     return true;
   }
 
   // C99 6.5.15p2
   if (CondTy->isScalarType()) return false;
 
   S.Diag(QuestionLoc, diag::err_typecheck_cond_expect_scalar)
     << CondTy << Cond->getSourceRange();
   return true;
 }
 
 /// Handle when one or both operands are void type.
 static QualType checkConditionalVoidType(Sema &S, ExprResult &LHS,
                                          ExprResult &RHS) {
     Expr *LHSExpr = LHS.get();
     Expr *RHSExpr = RHS.get();
QualType Sema::CheckConditionalOperands(ExprResult &Cond, ExprResult &LHS,
   if (getLangOpts().CPlusPlus)
     return CXXCheckConditionalOperands(Cond, LHS, RHS, VK, OK, QuestionLoc);
 
   VK = VK_RValue;
   OK = OK_Ordinary;
 
   // The OpenCL operator with a vector condition is sufficiently
   // different to merit its own checker.
-  if (getLangOpts().OpenCL && Cond.get()->getType()->isVectorType())
+  if ((getLangOpts().OpenCL && Cond.get()->getType()->isVectorType()) ||
+      Cond.get()->getType()->isExtVectorType())
     return OpenCLCheckVectorConditional(*this, Cond, LHS, RHS, QuestionLoc);
 
   // First, check the condition.
   Cond = UsualUnaryConversions(Cond.get());
   if (Cond.isInvalid())
     return QualType();
   if (checkCondition(*this, Cond.get(), QuestionLoc))
     return QualType();
 
   // Now check the two expressions.
   if (LHS.get()->getType()->isVectorType() ||
       RHS.get()->getType()->isVectorType())
     return CheckVectorOperands(LHS, RHS, QuestionLoc, /*isCompAssign*/false,
                                /*AllowBothBool*/true,
                                /*AllowBoolConversions*/false);
 
   QualType ResTy =
       UsualArithmeticConversions(LHS, RHS, QuestionLoc, ACK_Conditional);
   if (LHS.isInvalid() || RHS.isInvalid())
     return QualType();
 
   QualType LHSTy = LHS.get()->getType();
   QualType RHSTy = RHS.get()->getType();
 
   // Diagnose attempts to convert between __float128 and long double where
   // such conversions currently can't be handled.
   if (unsupportedTypeConversion(*this, LHSTy, RHSTy)) {
     Diag(QuestionLoc,
          diag::err_typecheck_cond_incompatible_operands) << LHSTy << RHSTy
       << LHS.get()->getSourceRange() << RHS.get()->getSourceRange();

clang/test/Sema/ext_vector_comparisons.c

static int4 test2() {
   // comparisons to self.  no warning, they're floats
   return vec == vec; // no-warning
   return vec != vec; // no-warning
   return vec < vec;  // no-warning
   return vec <= vec; // no-warning
   return vec > vec;  // no-warning
   return vec >= vec; // no-warning
 }
+
+static int4 test3() {
+  int4 i0, i1;
+
+  return i0 > i1 ? i0 : i1; // no-error
+  return i0 ? i0 : i1;      // no-error
+}
+
+static float4 test4() {
+  float4 f0, f1;
+
+  // This would actually generate implicit casting warning
+  // under Weverything flag but we don't really care here
+  return f0 > f1 ? f0 : f1; // no-error
+  return f0 ? f0 : f1;      // expected-error {{used type 'float4' (vector of 4 'float' values) where floating point type is not allowed}}
+}