[PATCH] D25866: [Sema] Support implicit scalar to vector conversions

[Bruno Cardoso Lopes via Phabricator via cfe-commits]

bruno added a comment.

Hey, really sorry for the delay here.



================
Comment at: lib/Sema/SemaExpr.cpp:8007
+static bool canConvertIntToOtherIntTy(Sema &S, ExprResult *Int,
+                                           QualType OtherIntTy) {
+  QualType IntTy = Int->get()->getType().getUnqualifiedType();
----------------
This doesn't look clang-formated. 


================
Comment at: lib/Sema/SemaExpr.cpp:8034
+        NumBits > S.Context.getIntWidth(OtherIntTy))
+      return true;
+  } else {
----------------
Instead of the else here, you can:
   ....
      return (IntSigned != OtherIntSigned &&
          NumBits > S.Context.getIntWidth(OtherIntTy))
   }

   return (Order < 0);


================
Comment at: lib/Sema/SemaExpr.cpp:8092
+                                        ExprResult *Vector) {
+  QualType ScalarTy = Scalar->get()->getType().getUnqualifiedType();
+  QualType VectorTy = Vector->get()->getType().getUnqualifiedType();
----------------
Can you please add an assertion to the beginning of this function to guarantee that the vector is never a ext-vector type? I wanna make sure we don't accidentally use this in the future for ext-vectors. 


================
Comment at: test/Sema/vector-gcc-compat.c:61
+  //        match.
+  v2i64_r = v2i64_a == 1; // expected-warning {{incompatible vector types assigning to 'v2i64' (vector of 2 'long long' values) from 'long __attribute__((ext_vector_type(2)))' (vector of 2 'long' values)}}
+  v2i64_r = v2i64_a != 1; // expected-warning {{incompatible vector types assigning to 'v2i64' (vector of 2 'long long' values) from 'long __attribute__((ext_vector_type(2)))' (vector of 2 'long' values)}}
----------------
Can you double check where 'long __attribute__((ext_vector_type(2)))' comes from?

We have regressed in the past year in the way ext-vector interacts with non-ext-vectors, and I don't wanna make it worse until we actually have time to fix that; there's a lot of code out there relying on bitcasts between ext-vectors and non-ext-vectors to bridge between intrinsics headers and ext-vector code.


https://reviews.llvm.org/D25866