[PATCH] D52074: [PowerPC] [Clang] Add vector int128 pack/unpack builtins

[Zixuan Wu via Phabricator via cfe-commits]

wuzish created this revision.
wuzish added reviewers: hfinkel, nemanjai, kbarton.
Herald added a subscriber: kristina.

> unsigned long long __builtin_unpack_vector_int128 (vector __int128_t, int);
>  vector __int128_t __builtin_pack_vector_int128 (unsigned long long, unsigned 
> long long);

Builtins should behave the same way as in GCC.


Repository:
  rC Clang

https://reviews.llvm.org/D52074

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/builtins-ppc-error.c
  clang/test/CodeGen/builtins-ppc-p7-disabled.c
  clang/test/CodeGen/builtins-ppc-vsx.c

Index: clang/test/CodeGen/builtins-ppc-vsx.c
===
--- clang/test/CodeGen/builtins-ppc-vsx.c
+++ clang/test/CodeGen/builtins-ppc-vsx.c
@@ -49,6 +49,7 @@
 vector bool long long res_vbll;
 vector signed long long res_vsll;
 vector unsigned long long res_vull;
+vector signed __int128 res_vslll;
 
 double res_d;
 float res_af[4];
@@ -1803,3 +1804,31 @@
 // CHECK-NEXT-LE:  shufflevector <4 x i32> %{{[0-9]+}}, <4 x i32> %{{[0-9]+}}, <4 x i32> 
 // CHECK-NEXT-LE:  bitcast <4 x i32> %{{[0-9]+}} to <2 x double>
 }
+
+void testVectorInt128Pack(){
+// CHECK-LABEL: testVectorInt128Pack
+// CHECK-LABEL-LE: testVectorInt128Pack
+  res_vslll = __builtin_pack_vector_int128(aull[0], aull[1]);
+// CHECK: %[[V1:[0-9]+]] = insertelement <2 x i64> undef, i64 %{{[0-9]+}}, i64 0
+// CHECK-NEXT: %[[V2:[0-9]+]] = insertelement <2 x i64> %[[V1]], i64 %{{[0-9]+}}, i64 1
+// CHECK-NEXT:  bitcast <2 x i64> %[[V2]] to <1 x i128>
+
+// CHECK-LE: %[[V1:[0-9]+]] = insertelement <2 x i64> undef, i64 %{{[0-9]+}}, i64 1
+// CHECK-NEXT-LE: %[[V2:[0-9]+]] = insertelement <2 x i64> %[[V1]], i64 %{{[0-9]+}}, i64 0
+// CHECK-NEXT-LE:  bitcast <2 x i64> %[[V2]] to <1 x i128>
+
+  __builtin_unpack_vector_int128(res_vslll, 0);
+// CHECK:  %[[V1:[0-9]+]] = bitcast <1 x i128> %{{[0-9]+}} to <2 x i64>
+// CHECK-NEXT: %{{[0-9]+}} = extractelement <2 x i64> %[[V1]], i32 0
+
+// CHECK-LE:  %[[V1:[0-9]+]] = bitcast <1 x i128> %{{[0-9]+}} to <2 x i64>
+// CHECK-NEXT-LE: %{{[0-9]+}} = extractelement <2 x i64> %[[V1]], i32 1
+
+  __builtin_unpack_vector_int128(res_vslll, 1);
+// CHECK:  %[[V1:[0-9]+]] = bitcast <1 x i128> %{{[0-9]+}} to <2 x i64>
+// CHECK-NEXT: %{{[0-9]+}} = extractelement <2 x i64> %[[V1]], i32 1
+
+// CHECK-LE:  %[[V1:[0-9]+]] = bitcast <1 x i128> %{{[0-9]+}} to <2 x i64>
+// CHECK-NEXT-LE: %{{[0-9]+}} = extractelement <2 x i64> %[[V1]], i32 0
+
+}
Index: clang/test/CodeGen/builtins-ppc-p7-disabled.c
===
--- clang/test/CodeGen/builtins-ppc-p7-disabled.c
+++ clang/test/CodeGen/builtins-ppc-p7-disabled.c
@@ -6,13 +6,17 @@
 // RUN: not %clang_cc1 -triple powerpc-unknown-unknown -emit-llvm %s -o - 2>&1 \
 // RUN: -target-cpu pwr7 | FileCheck %s -check-prefix=CHECK-32
 
+vector signed __int128 vslll = {33};
+
 void call_p7_builtins(void)
 {
   int a = __builtin_divwe(33, 11);
   unsigned int b = __builtin_divweu(33U, 11U);
   unsigned long long d = __builtin_divde(33ULL, 11ULL);
   unsigned long long e = __builtin_divdeu(33ULL, 11ULL);
   unsigned long long f = __builtin_bpermd(33ULL, 11ULL);
+  __builtin_pack_vector_int128(33ULL, 11ULL);
+  __builtin_unpack_vector_int128(vslll, 1);
 }
 
 // CHECK: error: this builtin is only valid on POWER7 or later CPUs
@@ -25,6 +29,10 @@
 // CHECK: __builtin_divdeu
 // CHECK: error: this builtin is only valid on POWER7 or later CPUs
 // CHECK: __builtin_bpermd
+// CHECK: error: this builtin is only valid on POWER7 or later CPUs
+// CHECK: __builtin_pack_vector_int128
+// CHECK: error: this builtin is only valid on POWER7 or later CPUs
+// CHECK: __builtin_unpack_vector_int128
 // CHECK-32: error: this builtin is only available on 64-bit targets
 // CHECK-32: __builtin_divde
 // CHECK-32: error: this builtin is only available on 64-bit targets
Index: clang/test/CodeGen/builtins-ppc-error.c
===
--- clang/test/CodeGen/builtins-ppc-error.c
+++ clang/test/CodeGen/builtins-ppc-error.c
@@ -14,6 +14,7 @@
 extern vector signed int vui;
 extern vector float vf;
 extern vector unsigned char vuc;
+extern vector signed __int128 vsllli;
 
 void testInsertWord(void) {
   int index = 5;
@@ -67,3 +68,8 @@
 void testVCTUXS(int index) {
   vec_vctuxs(vf, index); //expected-error {{argument to '__builtin_altivec_vctuxs' must be a constant integer}}
 }
+
+void testUnpack128(int index) {
+  __builtin_unpack_vector_int128(vsllli, index); //expected-error {{argument to '__builtin_unpack_vector_int128' must be a constant integer}}
+  __builtin_unpack_vector_int128(vsllli, 5); //expected-error {{argument value 5 is outside the valid range [0, 1]}}
+}
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/

[PATCH] D52074: [PowerPC] [Clang] Add vector int128 pack/unpack builtins

[Zixuan Wu via Phabricator via cfe-commits]

wuzish added a comment.

Please make this patch commit after https://reviews.llvm.org/D52072


Repository:
  rC Clang

https://reviews.llvm.org/D52074



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D53417: [Clang][PowerPC] Choose a better candidate as function call if there is a compatible vector conversion instead of ambious call error

[Zixuan Wu via Phabricator via cfe-commits]

wuzish created this revision.
wuzish added reviewers: hfinkel, nemanjai, Douglasgido, hubert.reinterpretcast, 
fpichet.

There are 2 function variations with altivec type parameter. When we call them 
with argument of generic gcc vector type we would prefer to choose the 
variation with implicit argument conversion of compatible vector type.

  typedef float __v4sf __attribute__((__vector_size__(16)));
  void f(vector float);
  void f(vector signed int);
  
  int main {
 __v4sf a;
 f(a);
  }

Here, we'd like to choose f(vector float) but not report an ambiguous call 
error.


Repository:
  rC Clang

https://reviews.llvm.org/D53417

Files:
  clang/lib/Sema/SemaOverload.cpp
  clang/test/Sema/altivec-generic-overload.c

Index: clang/test/Sema/altivec-generic-overload.c
===
--- /dev/null
+++ clang/test/Sema/altivec-generic-overload.c
@@ -0,0 +1,101 @@
+// RUN: %clang_cc1 %s -triple=powerpc64le-unknown-linux -target-feature +altivec -target-feature +vsx -verify -verify-ignore-unexpected=note -pedantic -fsyntax-only
+
+typedef signed char __v4sc __attribute__((__vector_size__(16)));
+typedef unsigned char __v4uc __attribute__((__vector_size__(16)));
+typedef signed short __v4ss __attribute__((__vector_size__(16)));
+typedef unsigned short __v4us __attribute__((__vector_size__(16)));
+typedef signed int __v4si __attribute__((__vector_size__(16)));
+typedef unsigned int __v4ui __attribute__((__vector_size__(16)));
+typedef signed long long __v4sll __attribute__((__vector_size__(16)));
+typedef unsigned long long __v4ull __attribute__((__vector_size__(16)));
+typedef signed __int128 __v4slll __attribute__((__vector_size__(16)));
+typedef unsigned __int128 __v4ulll __attribute__((__vector_size__(16)));
+typedef float __v4f __attribute__((__vector_size__(16)));
+typedef double __v4d __attribute__((__vector_size__(16)));
+
+void __attribute__((__overloadable__)) convert1(vector signed char);
+void __attribute__((__overloadable__)) convert1(vector unsigned char);
+void __attribute__((__overloadable__)) convert1(vector signed short);
+void __attribute__((__overloadable__)) convert1(vector unsigned short);
+void __attribute__((__overloadable__)) convert1(vector signed int);
+void __attribute__((__overloadable__)) convert1(vector unsigned int);
+void __attribute__((__overloadable__)) convert1(vector signed long long);
+void __attribute__((__overloadable__)) convert1(vector unsigned long long);
+void __attribute__((__overloadable__)) convert1(vector signed __int128);
+void __attribute__((__overloadable__)) convert1(vector unsigned __int128);
+void __attribute__((__overloadable__)) convert1(vector float);
+void __attribute__((__overloadable__)) convert1(vector double);
+void __attribute__((__overloadable__)) convert1(vector bool int);
+void __attribute__((__overloadable__)) convert1(vector pixel short);
+void __attribute__((__overloadable__)) convert2(__v4sc);
+void __attribute__((__overloadable__)) convert2(__v4uc);
+void __attribute__((__overloadable__)) convert2(__v4ss);
+void __attribute__((__overloadable__)) convert2(__v4us);
+void __attribute__((__overloadable__)) convert2(__v4si);
+void __attribute__((__overloadable__)) convert2(__v4ui);
+void __attribute__((__overloadable__)) convert2(__v4sll);
+void __attribute__((__overloadable__)) convert2(__v4ull);
+void __attribute__((__overloadable__)) convert2(__v4slll);
+void __attribute__((__overloadable__)) convert2(__v4ulll);
+void __attribute__((__overloadable__)) convert2(__v4f);
+void __attribute__((__overloadable__)) convert2(__v4d);
+
+void test()
+{
+  __v4sc gv1;
+  __v4uc gv2;
+  __v4ss gv3;
+  __v4us gv4;
+  __v4si gv5;
+  __v4ui gv6;
+  __v4sll gv7;
+  __v4ull gv8;
+  __v4slll gv9;
+  __v4ulll gv10;
+  __v4f gv11;
+  __v4d  gv12;
+
+  vector signed char av1;
+  vector unsigned char av2;
+  vector signed short av3;
+  vector unsigned short av4;
+  vector signed int av5;
+  vector unsigned int av6;
+  vector signed long long av7;
+  vector unsigned long long av8;
+  vector signed __int128 av9;
+  vector unsigned __int128 av10;
+  vector float av11;
+  vector double av12;
+  vector bool int av13;
+  vector pixel short av14;
+
+  convert1(gv1);
+  convert1(gv2);
+  convert1(gv3);
+  convert1(gv4);
+  convert1(gv5);
+  convert1(gv6);
+  convert1(gv7);
+  convert1(gv8);
+  convert1(gv9);
+  convert1(gv10);
+  convert1(gv11);
+  convert1(gv12);
+
+  convert2(av1);
+  convert2(av2);
+  convert2(av3);
+  convert2(av4);
+  convert2(av5);
+  convert2(av6);
+  convert2(av7);
+  convert2(av8);
+  convert2(av9);
+  convert2(av10);
+  convert2(av11);
+  convert2(av12);
+  convert2(av13); // expected-error {{call to 'convert2' is ambiguous}}
+  convert2(av14); // expected-error {{call to 'convert2' is ambiguous}}
+
+}
Index: clang/lib/Sema/SemaOverload.cpp
===
--- clang/lib/Sema/SemaOverload.cpp
+++ clang/lib/Sema/SemaOverload.cpp
@@ -3900,6 +3

[PATCH] D53417: [Clang][PowerPC] Choose a better candidate in overload function call if there is a compatible vector conversion instead of ambious call error

[Zixuan Wu via Phabricator via cfe-commits]

wuzish added a comment.

If anybody knows who are familiar with C/C++ function overload and code related 
to this issue, please feel free to add them as reviewers and subscribers.


Repository:
  rC Clang

https://reviews.llvm.org/D53417



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D53417: [Clang][PowerPC] Choose a better candidate in overload function call if there is a compatible vector conversion instead of ambiguous call error

[Zixuan Wu via Phabricator via cfe-commits]

wuzish added inline comments.



Comment at: clang/test/Sema/altivec-generic-overload.c:3
+
+typedef signed char __v4sc __attribute__((__vector_size__(16)));
+typedef unsigned char __v4uc __attribute__((__vector_size__(16)));

hubert.reinterpretcast wrote:
> `__v4sc` is suspicious. The most consistent naming I have seen is `v16i8`, 
> `v16u8`, `v8i16`, ...
> Do we need the double underscores?
> 
Because it's generic gcc vector type instead of altivec type so I choose the 
naming style.


Repository:
  rC Clang

https://reviews.llvm.org/D53417



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D53417: [Clang][PowerPC] Choose a better candidate in overload function call if there is a compatible vector conversion instead of ambiguous call error

[Zixuan Wu via Phabricator via cfe-commits]

wuzish marked 8 inline comments as done.
wuzish added inline comments.



Comment at: clang/lib/Sema/SemaOverload.cpp:3941
+  return ImplicitConversionSequence::Better;
+  }
+

hubert.reinterpretcast wrote:
> This seems to duplicate the bug described here in 
> https://bugs.llvm.org/show_bug.cgi?id=39361.
> ```
> typedef unsigned int GccType __attribute__((__vector_size__(16)));
> typedef __vector unsigned int AltiVecType;
> 
> typedef float GccOtherType __attribute__((__vector_size__(16)));
> 
> char *f(GccOtherType, int);
> template  int f(AltiVecType, T);
> template  int g(AltiVecType, T);
> char *g(GccOtherType, int);
> 
> bool zip(GccType v) { return f(v, 0) == g(v, 0); }
> ```
Thank you for the good case. I will fix it.

But the https://bugs.llvm.org/show_bug.cgi?id=39361 is not the same reason but 
similar. We can propose another patch to do this. I think the essential reason 
is that code as blow has not considered `ImplicitConversionSequence::Worse` so 
that outside caller goes into path to choose a non-template candidate first.


```
if (S.getLangOpts().MSVCCompat && SCS1.Second == ICK_Integral_Conversion &&
  SCS2.Second == ICK_Floating_Integral &&
  S.Context.getTypeSize(SCS1.getFromType()) ==
  S.Context.getTypeSize(SCS1.getToType(2)))
return ImplicitConversionSequence::Better;
```



Comment at: clang/test/Sema/altivec-generic-overload.c:3
+
+typedef signed char __v4sc __attribute__((__vector_size__(16)));
+typedef unsigned char __v4uc __attribute__((__vector_size__(16)));

hubert.reinterpretcast wrote:
> wuzish wrote:
> > hubert.reinterpretcast wrote:
> > > `__v4sc` is suspicious. The most consistent naming I have seen is 
> > > `v16i8`, `v16u8`, `v8i16`, ...
> > > Do we need the double underscores?
> > > 
> > Because it's generic gcc vector type instead of altivec type so I choose 
> > the naming style.
> The naming style from `clang/lib/Headers/avxintrin.h` would still say that 
> the `__v4sc` here should be `__v16qi`.
On, you mean the num. Yes, that should not be '4'. 


Repository:
  rC Clang

https://reviews.llvm.org/D53417



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D53417: [Clang][PowerPC] Choose a better candidate in overload function call if there is a compatible vector conversion instead of ambiguous call error

[Zixuan Wu via Phabricator via cfe-commits]

wuzish updated this revision to Diff 170871.
wuzish marked 2 inline comments as done.
wuzish added a comment.

Updated the diff.

fix some points from comments.


https://reviews.llvm.org/D53417

Files:
  clang/lib/Sema/SemaOverload.cpp
  clang/test/Sema/altivec-generic-overload.c

Index: clang/test/Sema/altivec-generic-overload.c
===
--- /dev/null
+++ clang/test/Sema/altivec-generic-overload.c
@@ -0,0 +1,101 @@
+// RUN: %clang_cc1 %s -triple=powerpc64le-unknown-linux -target-feature +altivec -target-feature +vsx -verify -verify-ignore-unexpected=note -pedantic -fsyntax-only
+
+typedef signed char __v16sc __attribute__((__vector_size__(16)));
+typedef unsigned char __v16uc __attribute__((__vector_size__(16)));
+typedef signed short __v8ss __attribute__((__vector_size__(16)));
+typedef unsigned short __v8us __attribute__((__vector_size__(16)));
+typedef signed int __v4si __attribute__((__vector_size__(16)));
+typedef unsigned int __v4ui __attribute__((__vector_size__(16)));
+typedef signed long long __v2sll __attribute__((__vector_size__(16)));
+typedef unsigned long long __v2ull __attribute__((__vector_size__(16)));
+typedef signed __int128 __v1slll __attribute__((__vector_size__(16)));
+typedef unsigned __int128 __v1ulll __attribute__((__vector_size__(16)));
+typedef float __v4f __attribute__((__vector_size__(16)));
+typedef double __v2d __attribute__((__vector_size__(16)));
+
+void __attribute__((__overloadable__)) convert1(vector signed char);
+void __attribute__((__overloadable__)) convert1(vector unsigned char);
+void __attribute__((__overloadable__)) convert1(vector signed short);
+void __attribute__((__overloadable__)) convert1(vector unsigned short);
+void __attribute__((__overloadable__)) convert1(vector signed int);
+void __attribute__((__overloadable__)) convert1(vector unsigned int);
+void __attribute__((__overloadable__)) convert1(vector signed long long);
+void __attribute__((__overloadable__)) convert1(vector unsigned long long);
+void __attribute__((__overloadable__)) convert1(vector signed __int128);
+void __attribute__((__overloadable__)) convert1(vector unsigned __int128);
+void __attribute__((__overloadable__)) convert1(vector float);
+void __attribute__((__overloadable__)) convert1(vector double);
+void __attribute__((__overloadable__)) convert1(vector bool int);
+void __attribute__((__overloadable__)) convert1(vector pixel short);
+void __attribute__((__overloadable__)) convert2(__v16sc);
+void __attribute__((__overloadable__)) convert2(__v16uc);
+void __attribute__((__overloadable__)) convert2(__v8ss);
+void __attribute__((__overloadable__)) convert2(__v8us);
+void __attribute__((__overloadable__)) convert2(__v4si);
+void __attribute__((__overloadable__)) convert2(__v4ui);
+void __attribute__((__overloadable__)) convert2(__v2sll);
+void __attribute__((__overloadable__)) convert2(__v2ull);
+void __attribute__((__overloadable__)) convert2(__v1slll);
+void __attribute__((__overloadable__)) convert2(__v1ulll);
+void __attribute__((__overloadable__)) convert2(__v4f);
+void __attribute__((__overloadable__)) convert2(__v2d);
+
+void test()
+{
+  __v16sc gv1;
+  __v16uc gv2;
+  __v8ss gv3;
+  __v8us gv4;
+  __v4si gv5;
+  __v4ui gv6;
+  __v2sll gv7;
+  __v2ull gv8;
+  __v1slll gv9;
+  __v1ulll gv10;
+  __v4f gv11;
+  __v2d  gv12;
+
+  vector signed char av1;
+  vector unsigned char av2;
+  vector signed short av3;
+  vector unsigned short av4;
+  vector signed int av5;
+  vector unsigned int av6;
+  vector signed long long av7;
+  vector unsigned long long av8;
+  vector signed __int128 av9;
+  vector unsigned __int128 av10;
+  vector float av11;
+  vector double av12;
+  vector bool int av13;
+  vector pixel short av14;
+
+  convert1(gv1);
+  convert1(gv2);
+  convert1(gv3);
+  convert1(gv4);
+  convert1(gv5);
+  convert1(gv6);
+  convert1(gv7);
+  convert1(gv8);
+  convert1(gv9);
+  convert1(gv10);
+  convert1(gv11);
+  convert1(gv12);
+
+  convert2(av1);
+  convert2(av2);
+  convert2(av3);
+  convert2(av4);
+  convert2(av5);
+  convert2(av6);
+  convert2(av7);
+  convert2(av8);
+  convert2(av9);
+  convert2(av10);
+  convert2(av11);
+  convert2(av12);
+  convert2(av13); // expected-error {{call to 'convert2' is ambiguous}}
+  convert2(av14); // expected-error {{call to 'convert2' is ambiguous}}
+
+}
Index: clang/lib/Sema/SemaOverload.cpp
===
--- clang/lib/Sema/SemaOverload.cpp
+++ clang/lib/Sema/SemaOverload.cpp
@@ -3900,6 +3900,56 @@
   S.Context.getTypeSize(SCS1.getToType(2)))
 return ImplicitConversionSequence::Better;
 
+  // For now only conversions with altivec-related kind and generic kind
+  // prefer to choose a compatible vector conversion
+  // FIXME: Can remove this constraint and extend to other vector kind?
+  auto IsPreferCompatibleConversionVectorKind =
+  [&S](const StandardConversionSequence &SCS1,
+   const StandardConve

[PATCH] D53417: [Clang][Sema][PowerPC] Choose a better candidate in overload function call if there is a compatible vector conversion instead of ambiguous call error

[Zixuan Wu via Phabricator via cfe-commits]

wuzish added inline comments.



Comment at: clang/lib/Sema/SemaOverload.cpp:3913
+for (auto Type : Types) {
+  if (S.Context.getCanonicalType(Type)->getTypeClass() != Type::Vector)
+return false;

hubert.reinterpretcast wrote:
> Considering that this is a local lambda called in one place, are we expecting 
> cases where the canonical type is not something on which we can call 
> getVectorKind()? If not, then we do not need this `if`.
Well, that's for ExtVectorType. I encounter some testcase failure because of 
that. So I just narrow the condition to only handle Type::Vector.

As the following comment said, so I treat it separately.

/// ExtVectorType - Extended vector type. This type is created using
/// __attribute__((ext_vector_type(n)), where "n" is the number of elements.
/// Unlike vector_size, ext_vector_type is only allowed on typedef's. This
/// class enables syntactic extensions, like Vector Components for accessing
/// points (as .xyzw), colors (as .rgba), and textures (modeled after OpenGL
/// Shading Language).


https://reviews.llvm.org/D53417



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D53417: [Clang][Sema][PowerPC] Choose a better candidate in overload function call if there is a compatible vector conversion instead of ambiguous call error

[Zixuan Wu via Phabricator via cfe-commits]

wuzish added inline comments.



Comment at: clang/lib/Sema/SemaOverload.cpp:3913
+for (auto Type : Types) {
+  if (S.Context.getCanonicalType(Type)->getTypeClass() != Type::Vector)
+return false;

hubert.reinterpretcast wrote:
> wuzish wrote:
> > hubert.reinterpretcast wrote:
> > > Considering that this is a local lambda called in one place, are we 
> > > expecting cases where the canonical type is not something on which we can 
> > > call getVectorKind()? If not, then we do not need this `if`.
> > Well, that's for ExtVectorType. I encounter some testcase failure because 
> > of that. So I just narrow the condition to only handle Type::Vector.
> > 
> > As the following comment said, so I treat it separately.
> > 
> > /// ExtVectorType - Extended vector type. This type is created using
> > /// __attribute__((ext_vector_type(n)), where "n" is the number of elements.
> > /// Unlike vector_size, ext_vector_type is only allowed on typedef's. This
> > /// class enables syntactic extensions, like Vector Components for accessing
> > /// points (as .xyzw), colors (as .rgba), and textures (modeled after OpenGL
> > /// Shading Language).
> An ExtVectorType is a VectorType, so what sort of failures are you hitting?
Yes. But the TypeClass of ExtVectorType is ExtVector.

some test points check the error report for ambiguous call because of too many 
implicit cast choices from ext_vector_type to vector type. Such as blow.


```
typedef char char16 __attribute__ ((__vector_size__ (16)));
typedef long long longlong16 __attribute__ ((__vector_size__ (16)));
typedef char char16_e __attribute__ ((__ext_vector_type__ (16)));
typedef long long longlong16_e __attribute__ ((__ext_vector_type__ (2)));


void f1_test(char16 c16, longlong16 ll16, char16_e c16e, longlong16_e ll16e) {
  int &ir1 = f1(c16);
  float &fr1 = f1(ll16);
  f1(c16e); // expected-error{{call to 'f1' is ambiguous}}
  f1(ll16e); // expected-error{{call to 'f1' is ambiguous}}
}
```

If we are gonna widen the condition, we can make a follow-up patch. Or we need 
include this condition and do this together in this patch?


https://reviews.llvm.org/D53417



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D53417: [Clang][Sema][PowerPC] Choose a better candidate in overload function call if there is a compatible vector conversion instead of ambiguous call error

[Zixuan Wu via Phabricator via cfe-commits]

wuzish added inline comments.



Comment at: clang/lib/Sema/SemaOverload.cpp:3913
+for (auto Type : Types) {
+  if (S.Context.getCanonicalType(Type)->getTypeClass() != Type::Vector)
+return false;

hubert.reinterpretcast wrote:
> wuzish wrote:
> > hubert.reinterpretcast wrote:
> > > wuzish wrote:
> > > > hubert.reinterpretcast wrote:
> > > > > Considering that this is a local lambda called in one place, are we 
> > > > > expecting cases where the canonical type is not something on which we 
> > > > > can call getVectorKind()? If not, then we do not need this `if`.
> > > > Well, that's for ExtVectorType. I encounter some testcase failure 
> > > > because of that. So I just narrow the condition to only handle 
> > > > Type::Vector.
> > > > 
> > > > As the following comment said, so I treat it separately.
> > > > 
> > > > /// ExtVectorType - Extended vector type. This type is created using
> > > > /// __attribute__((ext_vector_type(n)), where "n" is the number of 
> > > > elements.
> > > > /// Unlike vector_size, ext_vector_type is only allowed on typedef's. 
> > > > This
> > > > /// class enables syntactic extensions, like Vector Components for 
> > > > accessing
> > > > /// points (as .xyzw), colors (as .rgba), and textures (modeled after 
> > > > OpenGL
> > > > /// Shading Language).
> > > An ExtVectorType is a VectorType, so what sort of failures are you 
> > > hitting?
> > Yes. But the TypeClass of ExtVectorType is ExtVector.
> > 
> > some test points check the error report for ambiguous call because of too 
> > many implicit cast choices from ext_vector_type to vector type. Such as 
> > blow.
> > 
> > 
> > ```
> > typedef char char16 __attribute__ ((__vector_size__ (16)));
> > typedef long long longlong16 __attribute__ ((__vector_size__ (16)));
> > typedef char char16_e __attribute__ ((__ext_vector_type__ (16)));
> > typedef long long longlong16_e __attribute__ ((__ext_vector_type__ (2)));
> > 
> > 
> > void f1_test(char16 c16, longlong16 ll16, char16_e c16e, longlong16_e 
> > ll16e) {
> >   int &ir1 = f1(c16);
> >   float &fr1 = f1(ll16);
> >   f1(c16e); // expected-error{{call to 'f1' is ambiguous}}
> >   f1(ll16e); // expected-error{{call to 'f1' is ambiguous}}
> > }
> > ```
> > 
> > If we are gonna widen the condition, we can make a follow-up patch. Or we 
> > need include this condition and do this together in this patch?
> The widening that has occurred is in allowing the scope of the change to 
> encompass cases where AltiVec vectors are not sufficiently involved. The 
> change in behaviour makes sense, and perhaps the community may want to pursue 
> it; however, the mandate to make that level of change has not been given.
> 
> I do not believe that requiring that the TypeClass be VectorType is the 
> correct narrowing of the scope. Instead, we may want to consider requiring 
> that for each `SCS` in { `SCS1`, `SCS2` }, there is one AltiVec type and one 
> generic vector type in { `SCS.getFromType()`, `SCS.getToType(2)` }.
> 
The key point is that ExtVector is a kind of typeclass, **and** its vector kind 
is generic vector type.

So you think we should encompass ext_vector cases as a part of the scope of 
this patch? And modify the above cases' expected behavior (remove the 
**expected-error**)?


https://reviews.llvm.org/D53417



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D53417: [Clang][Sema][PowerPC] Choose a better candidate in overload function call if there is a compatible vector conversion instead of ambiguous call error

[Zixuan Wu via Phabricator via cfe-commits]

wuzish added inline comments.



Comment at: clang/lib/Sema/SemaOverload.cpp:3913
+for (auto Type : Types) {
+  if (S.Context.getCanonicalType(Type)->getTypeClass() != Type::Vector)
+return false;

hubert.reinterpretcast wrote:
> hubert.reinterpretcast wrote:
> > wuzish wrote:
> > > hubert.reinterpretcast wrote:
> > > > wuzish wrote:
> > > > > hubert.reinterpretcast wrote:
> > > > > > wuzish wrote:
> > > > > > > hubert.reinterpretcast wrote:
> > > > > > > > Considering that this is a local lambda called in one place, 
> > > > > > > > are we expecting cases where the canonical type is not 
> > > > > > > > something on which we can call getVectorKind()? If not, then we 
> > > > > > > > do not need this `if`.
> > > > > > > Well, that's for ExtVectorType. I encounter some testcase failure 
> > > > > > > because of that. So I just narrow the condition to only handle 
> > > > > > > Type::Vector.
> > > > > > > 
> > > > > > > As the following comment said, so I treat it separately.
> > > > > > > 
> > > > > > > /// ExtVectorType - Extended vector type. This type is created 
> > > > > > > using
> > > > > > > /// __attribute__((ext_vector_type(n)), where "n" is the number 
> > > > > > > of elements.
> > > > > > > /// Unlike vector_size, ext_vector_type is only allowed on 
> > > > > > > typedef's. This
> > > > > > > /// class enables syntactic extensions, like Vector Components 
> > > > > > > for accessing
> > > > > > > /// points (as .xyzw), colors (as .rgba), and textures (modeled 
> > > > > > > after OpenGL
> > > > > > > /// Shading Language).
> > > > > > An ExtVectorType is a VectorType, so what sort of failures are you 
> > > > > > hitting?
> > > > > Yes. But the TypeClass of ExtVectorType is ExtVector.
> > > > > 
> > > > > some test points check the error report for ambiguous call because of 
> > > > > too many implicit cast choices from ext_vector_type to vector type. 
> > > > > Such as blow.
> > > > > 
> > > > > 
> > > > > ```
> > > > > typedef char char16 __attribute__ ((__vector_size__ (16)));
> > > > > typedef long long longlong16 __attribute__ ((__vector_size__ (16)));
> > > > > typedef char char16_e __attribute__ ((__ext_vector_type__ (16)));
> > > > > typedef long long longlong16_e __attribute__ ((__ext_vector_type__ 
> > > > > (2)));
> > > > > 
> > > > > 
> > > > > void f1_test(char16 c16, longlong16 ll16, char16_e c16e, longlong16_e 
> > > > > ll16e) {
> > > > >   int &ir1 = f1(c16);
> > > > >   float &fr1 = f1(ll16);
> > > > >   f1(c16e); // expected-error{{call to 'f1' is ambiguous}}
> > > > >   f1(ll16e); // expected-error{{call to 'f1' is ambiguous}}
> > > > > }
> > > > > ```
> > > > > 
> > > > > If we are gonna widen the condition, we can make a follow-up patch. 
> > > > > Or we need include this condition and do this together in this patch?
> > > > The widening that has occurred is in allowing the scope of the change 
> > > > to encompass cases where AltiVec vectors are not sufficiently involved. 
> > > > The change in behaviour makes sense, and perhaps the community may want 
> > > > to pursue it; however, the mandate to make that level of change has not 
> > > > been given.
> > > > 
> > > > I do not believe that requiring that the TypeClass be VectorType is the 
> > > > correct narrowing of the scope. Instead, we may want to consider 
> > > > requiring that for each `SCS` in { `SCS1`, `SCS2` }, there is one 
> > > > AltiVec type and one generic vector type in { `SCS.getFromType()`, 
> > > > `SCS.getToType(2)` }.
> > > > 
> > > The key point is that ExtVector is a kind of typeclass, **and** its 
> > > vector kind is generic vector type.
> > > 
> > > So you think we should encompass ext_vector cases as a part of the scope 
> > > of this patch? And modify the above cases' expected behavior (remove the 
> > > **expected-error**)?
> > I gave a concrete suggested narrowing of the scope that does not exclude 
> > ExtVectorType or other derived types of VectorType. It also does not change 
> > the behaviour of the `f1_test` case above. We could pursue additional 
> > discussion over that case (separable from the current patch) on the mailing 
> > list.
> > 
> > I believe my suggestion does do something about this case:
> > ```
> > typedef unsigned int GccType __attribute__((__ext_vector_type__(16)));
> > typedef __vector unsigned int AltiVecType;
> > 
> > typedef float GccOtherType __attribute__((__vector_size__(16)));
> > 
> > void f(GccType);
> > void f(GccOtherType);
> > 
> > void g(AltiVecType v) { f(v); }
> > ```
> > 
> > I think that addressing the latter case is within the realm of things that 
> > we should consider for this patch. Either way, we should ensure that tests 
> > for AltiVec/__ext_vector_type__ conversions are available.
> Sorry, typo in the above case:
> ```
> typedef unsigned int GccType __attribute__((__ext_vector_type__(4)));
> ```
> 
OK, I understand what's your meaning. I just wanted to give you the condition 
of wha

[PATCH] D53417: [Clang][Sema][PowerPC] Choose a better candidate in overload function call if there is a compatible vector conversion instead of ambiguous call error

[Zixuan Wu via Phabricator via cfe-commits]

wuzish added inline comments.



Comment at: clang/lib/Sema/SemaOverload.cpp:3913
+for (auto Type : Types) {
+  if (S.Context.getCanonicalType(Type)->getTypeClass() != Type::Vector)
+return false;

hubert.reinterpretcast wrote:
> wuzish wrote:
> > hubert.reinterpretcast wrote:
> > > hubert.reinterpretcast wrote:
> > > > wuzish wrote:
> > > > > hubert.reinterpretcast wrote:
> > > > > > wuzish wrote:
> > > > > > > hubert.reinterpretcast wrote:
> > > > > > > > wuzish wrote:
> > > > > > > > > hubert.reinterpretcast wrote:
> > > > > > > > > > Considering that this is a local lambda called in one 
> > > > > > > > > > place, are we expecting cases where the canonical type is 
> > > > > > > > > > not something on which we can call getVectorKind()? If not, 
> > > > > > > > > > then we do not need this `if`.
> > > > > > > > > Well, that's for ExtVectorType. I encounter some testcase 
> > > > > > > > > failure because of that. So I just narrow the condition to 
> > > > > > > > > only handle Type::Vector.
> > > > > > > > > 
> > > > > > > > > As the following comment said, so I treat it separately.
> > > > > > > > > 
> > > > > > > > > /// ExtVectorType - Extended vector type. This type is 
> > > > > > > > > created using
> > > > > > > > > /// __attribute__((ext_vector_type(n)), where "n" is the 
> > > > > > > > > number of elements.
> > > > > > > > > /// Unlike vector_size, ext_vector_type is only allowed on 
> > > > > > > > > typedef's. This
> > > > > > > > > /// class enables syntactic extensions, like Vector 
> > > > > > > > > Components for accessing
> > > > > > > > > /// points (as .xyzw), colors (as .rgba), and textures 
> > > > > > > > > (modeled after OpenGL
> > > > > > > > > /// Shading Language).
> > > > > > > > An ExtVectorType is a VectorType, so what sort of failures are 
> > > > > > > > you hitting?
> > > > > > > Yes. But the TypeClass of ExtVectorType is ExtVector.
> > > > > > > 
> > > > > > > some test points check the error report for ambiguous call 
> > > > > > > because of too many implicit cast choices from ext_vector_type to 
> > > > > > > vector type. Such as blow.
> > > > > > > 
> > > > > > > 
> > > > > > > ```
> > > > > > > typedef char char16 __attribute__ ((__vector_size__ (16)));
> > > > > > > typedef long long longlong16 __attribute__ ((__vector_size__ 
> > > > > > > (16)));
> > > > > > > typedef char char16_e __attribute__ ((__ext_vector_type__ (16)));
> > > > > > > typedef long long longlong16_e __attribute__ 
> > > > > > > ((__ext_vector_type__ (2)));
> > > > > > > 
> > > > > > > 
> > > > > > > void f1_test(char16 c16, longlong16 ll16, char16_e c16e, 
> > > > > > > longlong16_e ll16e) {
> > > > > > >   int &ir1 = f1(c16);
> > > > > > >   float &fr1 = f1(ll16);
> > > > > > >   f1(c16e); // expected-error{{call to 'f1' is ambiguous}}
> > > > > > >   f1(ll16e); // expected-error{{call to 'f1' is ambiguous}}
> > > > > > > }
> > > > > > > ```
> > > > > > > 
> > > > > > > If we are gonna widen the condition, we can make a follow-up 
> > > > > > > patch. Or we need include this condition and do this together in 
> > > > > > > this patch?
> > > > > > The widening that has occurred is in allowing the scope of the 
> > > > > > change to encompass cases where AltiVec vectors are not 
> > > > > > sufficiently involved. The change in behaviour makes sense, and 
> > > > > > perhaps the community may want to pursue it; however, the mandate 
> > > > > > to make that level of change has not been given.
> > > > > > 
> > > > > > I do not believe that requiring that the TypeClass be VectorType is 
> > > > > > the correct narrowing of the scope. Instead, we may want to 
> > > > > > consider requiring that for each `SCS` in { `SCS1`, `SCS2` }, there 
> > > > > > is one AltiVec type and one generic vector type in { 
> > > > > > `SCS.getFromType()`, `SCS.getToType(2)` }.
> > > > > > 
> > > > > The key point is that ExtVector is a kind of typeclass, **and** its 
> > > > > vector kind is generic vector type.
> > > > > 
> > > > > So you think we should encompass ext_vector cases as a part of the 
> > > > > scope of this patch? And modify the above cases' expected behavior 
> > > > > (remove the **expected-error**)?
> > > > I gave a concrete suggested narrowing of the scope that does not 
> > > > exclude ExtVectorType or other derived types of VectorType. It also 
> > > > does not change the behaviour of the `f1_test` case above. We could 
> > > > pursue additional discussion over that case (separable from the current 
> > > > patch) on the mailing list.
> > > > 
> > > > I believe my suggestion does do something about this case:
> > > > ```
> > > > typedef unsigned int GccType __attribute__((__ext_vector_type__(16)));
> > > > typedef __vector unsigned int AltiVecType;
> > > > 
> > > > typedef float GccOtherType __attribute__((__vector_size__(16)));
> > > > 
> > > > void f(GccType);
> > > > void f(GccOtherType);
> > > > 
> > > > void g(AltiVecType v) { f(v);

[PATCH] D54087: [PowerPC] [Clang] [AltiVec] The second parameter of vec_sr function should be modulo the number of bits in the element

[Zixuan Wu via Phabricator via cfe-commits]

wuzish created this revision.
wuzish added reviewers: hfinkel, nemanjai, kbarton.
Herald added a subscriber: jsji.

The second parameter of vec_sr function is representing shift bits and it 
should be modulo the number of bits in the element like what vec_sl does now.


Repository:
  rC Clang

https://reviews.llvm.org/D54087

Files:
  clang/lib/Headers/altivec.h
  clang/test/CodeGen/builtins-ppc-altivec.c
  clang/test/CodeGen/builtins-ppc-p8vector.c

Index: clang/test/CodeGen/builtins-ppc-p8vector.c
===
--- clang/test/CodeGen/builtins-ppc-p8vector.c
+++ clang/test/CodeGen/builtins-ppc-p8vector.c
@@ -1066,13 +1066,17 @@
 
   /* vec_sr */
   res_vsll = vec_sr(vsll, vull);
-// CHECK: lshr <2 x i64>
-// CHECK-LE: lshr <2 x i64>
+// CHECK: [[UREM:[0-9a-zA-Z%.]+]] = urem <2 x i64> {{[0-9a-zA-Z%.]+}}, 
+// CHECK: lshr <2 x i64> {{[0-9a-zA-Z%.]+}}, [[UREM]]
+// CHECK-LE: [[UREM:[0-9a-zA-Z%.]+]] = urem <2 x i64> {{[0-9a-zA-Z%.]+}}, 
+// CHECK-LE: lshr <2 x i64> {{[0-9a-zA-Z%.]+}}, [[UREM]]
 // CHECK-PPC: error: call to 'vec_sr' is ambiguous
 
   res_vull = vec_sr(vull, vull);
-// CHECK: lshr <2 x i64>
-// CHECK-LE: lshr <2 x i64>
+// CHECK: [[UREM:[0-9a-zA-Z%.]+]] = urem <2 x i64> {{[0-9a-zA-Z%.]+}}, 
+// CHECK: lshr <2 x i64> {{[0-9a-zA-Z%.]+}}, [[UREM]]
+// CHECK-LE: [[UREM:[0-9a-zA-Z%.]+]] = urem <2 x i64> {{[0-9a-zA-Z%.]+}}, 
+// CHECK-LE: lshr <2 x i64> {{[0-9a-zA-Z%.]+}}, [[UREM]]
 // CHECK-PPC: error: call to 'vec_sr' is ambiguous
 
   /* vec_sra */
Index: clang/test/CodeGen/builtins-ppc-altivec.c
===
--- clang/test/CodeGen/builtins-ppc-altivec.c
+++ clang/test/CodeGen/builtins-ppc-altivec.c
@@ -4256,52 +4256,76 @@
 
   /* vec_sr */
   res_vsc = vec_sr(vsc, vuc);
-// CHECK: lshr <16 x i8>
-// CHECK-LE: lshr <16 x i8>
+// CHECK: [[UREM:[0-9a-zA-Z%.]+]] = urem <16 x i8> {{[0-9a-zA-Z%.]+}}, 
+// CHECK: lshr <16 x i8> {{[0-9a-zA-Z%.]+}}, [[UREM]]
+// CHECK-LE: [[UREM:[0-9a-zA-Z%.]+]] = urem <16 x i8> {{[0-9a-zA-Z%.]+}}, 
+// CHECK-LE: lshr <16 x i8> {{[0-9a-zA-Z%.]+}}, [[UREM]]
 
   res_vuc = vec_sr(vuc, vuc);
-// CHECK: lshr <16 x i8>
-// CHECK-LE: lshr <16 x i8>
+// CHECK: [[UREM:[0-9a-zA-Z%.]+]] = urem <16 x i8> {{[0-9a-zA-Z%.]+}}, 
+// CHECK: lshr <16 x i8> {{[0-9a-zA-Z%.]+}}, [[UREM]]
+// CHECK-LE: [[UREM:[0-9a-zA-Z%.]+]] = urem <16 x i8> {{[0-9a-zA-Z%.]+}}, 
+// CHECK-LE: lshr <16 x i8> {{[0-9a-zA-Z%.]+}}, [[UREM]]
 
   res_vs  = vec_sr(vs, vus);
-// CHECK: lshr <8 x i16>
-// CHECK-LE: lshr <8 x i16>
+// CHECK: [[UREM:[0-9a-zA-Z%.]+]] = urem <8 x i16> {{[0-9a-zA-Z%.]+}}, 
+// CHECK: lshr <8 x i16> {{[0-9a-zA-Z%.]+}}, [[UREM]]
+// CHECK-LE: [[UREM:[0-9a-zA-Z%.]+]] = urem <8 x i16> {{[0-9a-zA-Z%.]+}}, 
+// CHECK-LE: lshr <8 x i16> {{[0-9a-zA-Z%.]+}}, [[UREM]]
 
   res_vus = vec_sr(vus, vus);
-// CHECK: lshr <8 x i16>
-// CHECK-LE: lshr <8 x i16>
+// CHECK: [[UREM:[0-9a-zA-Z%.]+]] = urem <8 x i16> {{[0-9a-zA-Z%.]+}}, 
+// CHECK: lshr <8 x i16> {{[0-9a-zA-Z%.]+}}, [[UREM]]
+// CHECK-LE: [[UREM:[0-9a-zA-Z%.]+]] = urem <8 x i16> {{[0-9a-zA-Z%.]+}}, 
+// CHECK-LE: lshr <8 x i16> {{[0-9a-zA-Z%.]+}}, [[UREM]]
 
   res_vi  = vec_sr(vi, vui);
-// CHECK: lshr <4 x i32>
-// CHECK-LE: lshr <4 x i32>
+// CHECK: [[UREM:[0-9a-zA-Z%.]+]] = urem <4 x i32> {{[0-9a-zA-Z%.]+}}, 
+// CHECK: lshr <4 x i32> {{[0-9a-zA-Z%.]+}}, [[UREM]]
+// CHECK-LE: [[UREM:[0-9a-zA-Z%.]+]] = urem <4 x i32> {{[0-9a-zA-Z%.]+}}, 
+// CHECK-LE: lshr <4 x i32> {{[0-9a-zA-Z%.]+}}, [[UREM]]
 
   res_vui = vec_sr(vui, vui);
-// CHECK: lshr <4 x i32>
-// CHECK-LE: lshr <4 x i32>
+// CHECK: [[UREM:[0-9a-zA-Z%.]+]] = urem <4 x i32> {{[0-9a-zA-Z%.]+}}, 
+// CHECK: lshr <4 x i32> {{[0-9a-zA-Z%.]+}}, [[UREM]]
+// CHECK-LE: [[UREM:[0-9a-zA-Z%.]+]] = urem <4 x i32> {{[0-9a-zA-Z%.]+}}, 
+// CHECK-LE: lshr <4 x i32> {{[0-9a-zA-Z%.]+}}, [[UREM]]
 
   res_vsc = vec_vsrb(vsc, vuc);
-// CHECK: shr <16 x i8>
-// CHECK-LE: shr <16 x i8>
+// CHECK: [[UREM:[0-9a-zA-Z%.]+]] = urem <16 x i8> {{[0-9a-zA-Z%.]+}}, 
+// CHECK: lshr <16 x i8> {{[0-9a-zA-Z%.]+}}, [[UREM]]
+// CHECK-LE: [[UREM:[0-9a-zA-Z%.]+]] = urem <16 x i8> {{[0-9a-zA-Z%.]+}}, 
+// CHECK-LE: lshr <16 x i8> {{[0-9a-zA-Z%.]+}}, [[UREM]]
 
   res_vuc = vec_vsrb(vuc, vuc);
-// CHECK: shr <16 x i8>
-// CHECK-LE: shr <16 x i8>
+// CHECK: [[UREM:[0-9a-zA-Z%.]+]] = urem <16 x i8> {{[0-9a-zA-Z%.]+}}, 
+// CHECK: lshr <16 x i8> {{[0-9a-zA-Z%.]+}}, [[UREM]]
+// CHECK-LE: [[UREM:[0-9a-zA-Z%.]+]] = urem <16 x i8> {{[0-9a-zA-Z%.]+}}, 
+// CHECK-LE: lshr <16 x i8> {{[0-9a-zA-Z%.]+}}, [[UREM]]
 
   res_vs  = vec_vsrh(vs, vus);
-// CHECK: shr <8 x i16>
-// CHECK-LE: shr <8 x i16>
+// CHECK: [[UREM:[0-9a-zA-Z%.]+]] = urem <8 x i16> {{[0-9a-zA-Z%.]+}}, 
+// CHECK: lshr <8 x i16> {{[0-9a-zA-Z%.]+}}, [[UREM]]
+// CHECK-LE: [[UREM:[0-9a-zA-Z%.]+]] = urem <8 x i16> {{[0-9a-zA-Z%.]+}}, 
+// CHECK-LE: lshr <8 x i16> {{[0-9a-zA-Z%.]+}}, [[UREM]]
 
   res_vus = vec_vsrh(vus, vus);
-// CHECK: shr <8 x i16>
-// CHE

[PATCH] D53417: [Clang][Sema][PowerPC] Choose a better candidate in overload function call if there is a compatible vector conversion instead of ambiguous call error

[Zixuan Wu via Phabricator via cfe-commits]

wuzish marked an inline comment as done.
wuzish added a comment.

Gentle ping. Could anyone else have a more review?


https://reviews.llvm.org/D53417



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D53417: [Clang][Sema][PowerPC] Choose a better candidate in overload function call if there is a compatible vector conversion instead of ambiguous call error

[Zixuan Wu via Phabricator via cfe-commits]

wuzish marked an inline comment as done.
wuzish added inline comments.



Comment at: clang/lib/Sema/SemaOverload.cpp:3913
+for (auto Type : Types) {
+  if (S.Context.getCanonicalType(Type)->getTypeClass() != Type::Vector)
+return false;

hubert.reinterpretcast wrote:
> wuzish wrote:
> > hubert.reinterpretcast wrote:
> > > wuzish wrote:
> > > > hubert.reinterpretcast wrote:
> > > > > hubert.reinterpretcast wrote:
> > > > > > wuzish wrote:
> > > > > > > hubert.reinterpretcast wrote:
> > > > > > > > wuzish wrote:
> > > > > > > > > hubert.reinterpretcast wrote:
> > > > > > > > > > wuzish wrote:
> > > > > > > > > > > hubert.reinterpretcast wrote:
> > > > > > > > > > > > Considering that this is a local lambda called in one 
> > > > > > > > > > > > place, are we expecting cases where the canonical type 
> > > > > > > > > > > > is not something on which we can call getVectorKind()? 
> > > > > > > > > > > > If not, then we do not need this `if`.
> > > > > > > > > > > Well, that's for ExtVectorType. I encounter some testcase 
> > > > > > > > > > > failure because of that. So I just narrow the condition 
> > > > > > > > > > > to only handle Type::Vector.
> > > > > > > > > > > 
> > > > > > > > > > > As the following comment said, so I treat it separately.
> > > > > > > > > > > 
> > > > > > > > > > > /// ExtVectorType - Extended vector type. This type is 
> > > > > > > > > > > created using
> > > > > > > > > > > /// __attribute__((ext_vector_type(n)), where "n" is the 
> > > > > > > > > > > number of elements.
> > > > > > > > > > > /// Unlike vector_size, ext_vector_type is only allowed 
> > > > > > > > > > > on typedef's. This
> > > > > > > > > > > /// class enables syntactic extensions, like Vector 
> > > > > > > > > > > Components for accessing
> > > > > > > > > > > /// points (as .xyzw), colors (as .rgba), and textures 
> > > > > > > > > > > (modeled after OpenGL
> > > > > > > > > > > /// Shading Language).
> > > > > > > > > > An ExtVectorType is a VectorType, so what sort of failures 
> > > > > > > > > > are you hitting?
> > > > > > > > > Yes. But the TypeClass of ExtVectorType is ExtVector.
> > > > > > > > > 
> > > > > > > > > some test points check the error report for ambiguous call 
> > > > > > > > > because of too many implicit cast choices from 
> > > > > > > > > ext_vector_type to vector type. Such as blow.
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > ```
> > > > > > > > > typedef char char16 __attribute__ ((__vector_size__ (16)));
> > > > > > > > > typedef long long longlong16 __attribute__ ((__vector_size__ 
> > > > > > > > > (16)));
> > > > > > > > > typedef char char16_e __attribute__ ((__ext_vector_type__ 
> > > > > > > > > (16)));
> > > > > > > > > typedef long long longlong16_e __attribute__ 
> > > > > > > > > ((__ext_vector_type__ (2)));
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > void f1_test(char16 c16, longlong16 ll16, char16_e c16e, 
> > > > > > > > > longlong16_e ll16e) {
> > > > > > > > >   int &ir1 = f1(c16);
> > > > > > > > >   float &fr1 = f1(ll16);
> > > > > > > > >   f1(c16e); // expected-error{{call to 'f1' is ambiguous}}
> > > > > > > > >   f1(ll16e); // expected-error{{call to 'f1' is ambiguous}}
> > > > > > > > > }
> > > > > > > > > ```
> > > > > > > > > 
> > > > > > > > > If we are gonna widen the condition, we can make a follow-up 
> > > > > > > > > patch. Or we need include this condition and do this together 
> > > > > > > > > in this patch?
> > > > > > > > The widening that has occurred is in allowing the scope of the 
> > > > > > > > change to encompass cases where AltiVec vectors are not 
> > > > > > > > sufficiently involved. The change in behaviour makes sense, and 
> > > > > > > > perhaps the community may want to pursue it; however, the 
> > > > > > > > mandate to make that level of change has not been given.
> > > > > > > > 
> > > > > > > > I do not believe that requiring that the TypeClass be 
> > > > > > > > VectorType is the correct narrowing of the scope. Instead, we 
> > > > > > > > may want to consider requiring that for each `SCS` in { `SCS1`, 
> > > > > > > > `SCS2` }, there is one AltiVec type and one generic vector type 
> > > > > > > > in { `SCS.getFromType()`, `SCS.getToType(2)` }.
> > > > > > > > 
> > > > > > > The key point is that ExtVector is a kind of typeclass, **and** 
> > > > > > > its vector kind is generic vector type.
> > > > > > > 
> > > > > > > So you think we should encompass ext_vector cases as a part of 
> > > > > > > the scope of this patch? And modify the above cases' expected 
> > > > > > > behavior (remove the **expected-error**)?
> > > > > > I gave a concrete suggested narrowing of the scope that does not 
> > > > > > exclude ExtVectorType or other derived types of VectorType. It also 
> > > > > > does not change the behaviour of the `f1_test` case above. We could 
> > > > > > pursue additional discussion over that case (separable from the 
> > > > > > curr

[PATCH] D53417: [Clang][Sema][PowerPC] Choose a better candidate in overload function call if there is a compatible vector conversion instead of ambiguous call error

[Zixuan Wu via Phabricator via cfe-commits]

wuzish added a comment.

Gentle ping again since it's a critical patch. Could you please have a more 
review or give it LGTM if it's LGTM to you. Also welcome new comments.


https://reviews.llvm.org/D53417



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D54087: [PowerPC] [Clang] [AltiVec] The second parameter of vec_sr function should be modulo the number of bits in the element

[Zixuan Wu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rC346471: [PowerPC] [Clang] [AltiVec] The second parameter of 
vec_sr function should be… (authored by wuzish, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D54087?vs=172538&id=173262#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D54087

Files:
  lib/Headers/altivec.h
  test/CodeGen/builtins-ppc-altivec.c
  test/CodeGen/builtins-ppc-p8vector.c

Index: test/CodeGen/builtins-ppc-p8vector.c
===
--- test/CodeGen/builtins-ppc-p8vector.c
+++ test/CodeGen/builtins-ppc-p8vector.c
@@ -1066,13 +1066,17 @@
 
   /* vec_sr */
   res_vsll = vec_sr(vsll, vull);
-// CHECK: lshr <2 x i64>
-// CHECK-LE: lshr <2 x i64>
+// CHECK: [[UREM:[0-9a-zA-Z%.]+]] = urem <2 x i64> {{[0-9a-zA-Z%.]+}}, 
+// CHECK: lshr <2 x i64> {{[0-9a-zA-Z%.]+}}, [[UREM]]
+// CHECK-LE: [[UREM:[0-9a-zA-Z%.]+]] = urem <2 x i64> {{[0-9a-zA-Z%.]+}}, 
+// CHECK-LE: lshr <2 x i64> {{[0-9a-zA-Z%.]+}}, [[UREM]]
 // CHECK-PPC: error: call to 'vec_sr' is ambiguous
 
   res_vull = vec_sr(vull, vull);
-// CHECK: lshr <2 x i64>
-// CHECK-LE: lshr <2 x i64>
+// CHECK: [[UREM:[0-9a-zA-Z%.]+]] = urem <2 x i64> {{[0-9a-zA-Z%.]+}}, 
+// CHECK: lshr <2 x i64> {{[0-9a-zA-Z%.]+}}, [[UREM]]
+// CHECK-LE: [[UREM:[0-9a-zA-Z%.]+]] = urem <2 x i64> {{[0-9a-zA-Z%.]+}}, 
+// CHECK-LE: lshr <2 x i64> {{[0-9a-zA-Z%.]+}}, [[UREM]]
 // CHECK-PPC: error: call to 'vec_sr' is ambiguous
 
   /* vec_sra */
Index: test/CodeGen/builtins-ppc-altivec.c
===
--- test/CodeGen/builtins-ppc-altivec.c
+++ test/CodeGen/builtins-ppc-altivec.c
@@ -4256,52 +4256,76 @@
 
   /* vec_sr */
   res_vsc = vec_sr(vsc, vuc);
-// CHECK: lshr <16 x i8>
-// CHECK-LE: lshr <16 x i8>
+// CHECK: [[UREM:[0-9a-zA-Z%.]+]] = urem <16 x i8> {{[0-9a-zA-Z%.]+}}, 
+// CHECK: lshr <16 x i8> {{[0-9a-zA-Z%.]+}}, [[UREM]]
+// CHECK-LE: [[UREM:[0-9a-zA-Z%.]+]] = urem <16 x i8> {{[0-9a-zA-Z%.]+}}, 
+// CHECK-LE: lshr <16 x i8> {{[0-9a-zA-Z%.]+}}, [[UREM]]
 
   res_vuc = vec_sr(vuc, vuc);
-// CHECK: lshr <16 x i8>
-// CHECK-LE: lshr <16 x i8>
+// CHECK: [[UREM:[0-9a-zA-Z%.]+]] = urem <16 x i8> {{[0-9a-zA-Z%.]+}}, 
+// CHECK: lshr <16 x i8> {{[0-9a-zA-Z%.]+}}, [[UREM]]
+// CHECK-LE: [[UREM:[0-9a-zA-Z%.]+]] = urem <16 x i8> {{[0-9a-zA-Z%.]+}}, 
+// CHECK-LE: lshr <16 x i8> {{[0-9a-zA-Z%.]+}}, [[UREM]]
 
   res_vs  = vec_sr(vs, vus);
-// CHECK: lshr <8 x i16>
-// CHECK-LE: lshr <8 x i16>
+// CHECK: [[UREM:[0-9a-zA-Z%.]+]] = urem <8 x i16> {{[0-9a-zA-Z%.]+}}, 
+// CHECK: lshr <8 x i16> {{[0-9a-zA-Z%.]+}}, [[UREM]]
+// CHECK-LE: [[UREM:[0-9a-zA-Z%.]+]] = urem <8 x i16> {{[0-9a-zA-Z%.]+}}, 
+// CHECK-LE: lshr <8 x i16> {{[0-9a-zA-Z%.]+}}, [[UREM]]
 
   res_vus = vec_sr(vus, vus);
-// CHECK: lshr <8 x i16>
-// CHECK-LE: lshr <8 x i16>
+// CHECK: [[UREM:[0-9a-zA-Z%.]+]] = urem <8 x i16> {{[0-9a-zA-Z%.]+}}, 
+// CHECK: lshr <8 x i16> {{[0-9a-zA-Z%.]+}}, [[UREM]]
+// CHECK-LE: [[UREM:[0-9a-zA-Z%.]+]] = urem <8 x i16> {{[0-9a-zA-Z%.]+}}, 
+// CHECK-LE: lshr <8 x i16> {{[0-9a-zA-Z%.]+}}, [[UREM]]
 
   res_vi  = vec_sr(vi, vui);
-// CHECK: lshr <4 x i32>
-// CHECK-LE: lshr <4 x i32>
+// CHECK: [[UREM:[0-9a-zA-Z%.]+]] = urem <4 x i32> {{[0-9a-zA-Z%.]+}}, 
+// CHECK: lshr <4 x i32> {{[0-9a-zA-Z%.]+}}, [[UREM]]
+// CHECK-LE: [[UREM:[0-9a-zA-Z%.]+]] = urem <4 x i32> {{[0-9a-zA-Z%.]+}}, 
+// CHECK-LE: lshr <4 x i32> {{[0-9a-zA-Z%.]+}}, [[UREM]]
 
   res_vui = vec_sr(vui, vui);
-// CHECK: lshr <4 x i32>
-// CHECK-LE: lshr <4 x i32>
+// CHECK: [[UREM:[0-9a-zA-Z%.]+]] = urem <4 x i32> {{[0-9a-zA-Z%.]+}}, 
+// CHECK: lshr <4 x i32> {{[0-9a-zA-Z%.]+}}, [[UREM]]
+// CHECK-LE: [[UREM:[0-9a-zA-Z%.]+]] = urem <4 x i32> {{[0-9a-zA-Z%.]+}}, 
+// CHECK-LE: lshr <4 x i32> {{[0-9a-zA-Z%.]+}}, [[UREM]]
 
   res_vsc = vec_vsrb(vsc, vuc);
-// CHECK: shr <16 x i8>
-// CHECK-LE: shr <16 x i8>
+// CHECK: [[UREM:[0-9a-zA-Z%.]+]] = urem <16 x i8> {{[0-9a-zA-Z%.]+}}, 
+// CHECK: lshr <16 x i8> {{[0-9a-zA-Z%.]+}}, [[UREM]]
+// CHECK-LE: [[UREM:[0-9a-zA-Z%.]+]] = urem <16 x i8> {{[0-9a-zA-Z%.]+}}, 
+// CHECK-LE: lshr <16 x i8> {{[0-9a-zA-Z%.]+}}, [[UREM]]
 
   res_vuc = vec_vsrb(vuc, vuc);
-// CHECK: shr <16 x i8>
-// CHECK-LE: shr <16 x i8>
+// CHECK: [[UREM:[0-9a-zA-Z%.]+]] = urem <16 x i8> {{[0-9a-zA-Z%.]+}}, 
+// CHECK: lshr <16 x i8> {{[0-9a-zA-Z%.]+}}, [[UREM]]
+// CHECK-LE: [[UREM:[0-9a-zA-Z%.]+]] = urem <16 x i8> {{[0-9a-zA-Z%.]+}}, 
+// CHECK-LE: lshr <16 x i8> {{[0-9a-zA-Z%.]+}}, [[UREM]]
 
   res_vs  = vec_vsrh(vs, vus);
-// CHECK: shr <8 x i16>
-// CHECK-LE: shr <8 x i16>
+// CHECK: [[UREM:[0-9a-zA-Z%.]+]] = urem <8 x i16> {{[0-9a-zA-Z%.]+}}, 
+// CHECK: lshr <8 x i16> {{[0-9a-zA-Z%.]+}}, [[UREM]]
+// CHECK-LE: [[UREM:[0-9a-zA-Z%.]+]] = urem <8 x i16> {{[0-9a-zA-Z%.]+}}, 
+// CHECK-LE: lshr <8 x i16> {{[0-9a-zA-Z%.]+}}, [[UREM]]
 
   res_vus = vec_vsrh(vus, vus);
-// CHECK: shr <8 x i16>
-// CHECK-LE: shr <8 x i16>
+/

[PATCH] D54087: [PowerPC] [Clang] [AltiVec] The second parameter of vec_sr function should be modulo the number of bits in the element

[Zixuan Wu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL346471: [PowerPC] [Clang] [AltiVec] The second parameter of 
vec_sr function should be… (authored by wuzish, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D54087?vs=172538&id=173263#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D54087

Files:
  cfe/trunk/lib/Headers/altivec.h
  cfe/trunk/test/CodeGen/builtins-ppc-altivec.c
  cfe/trunk/test/CodeGen/builtins-ppc-p8vector.c

Index: cfe/trunk/test/CodeGen/builtins-ppc-altivec.c
===
--- cfe/trunk/test/CodeGen/builtins-ppc-altivec.c
+++ cfe/trunk/test/CodeGen/builtins-ppc-altivec.c
@@ -4256,52 +4256,76 @@
 
   /* vec_sr */
   res_vsc = vec_sr(vsc, vuc);
-// CHECK: lshr <16 x i8>
-// CHECK-LE: lshr <16 x i8>
+// CHECK: [[UREM:[0-9a-zA-Z%.]+]] = urem <16 x i8> {{[0-9a-zA-Z%.]+}}, 
+// CHECK: lshr <16 x i8> {{[0-9a-zA-Z%.]+}}, [[UREM]]
+// CHECK-LE: [[UREM:[0-9a-zA-Z%.]+]] = urem <16 x i8> {{[0-9a-zA-Z%.]+}}, 
+// CHECK-LE: lshr <16 x i8> {{[0-9a-zA-Z%.]+}}, [[UREM]]
 
   res_vuc = vec_sr(vuc, vuc);
-// CHECK: lshr <16 x i8>
-// CHECK-LE: lshr <16 x i8>
+// CHECK: [[UREM:[0-9a-zA-Z%.]+]] = urem <16 x i8> {{[0-9a-zA-Z%.]+}}, 
+// CHECK: lshr <16 x i8> {{[0-9a-zA-Z%.]+}}, [[UREM]]
+// CHECK-LE: [[UREM:[0-9a-zA-Z%.]+]] = urem <16 x i8> {{[0-9a-zA-Z%.]+}}, 
+// CHECK-LE: lshr <16 x i8> {{[0-9a-zA-Z%.]+}}, [[UREM]]
 
   res_vs  = vec_sr(vs, vus);
-// CHECK: lshr <8 x i16>
-// CHECK-LE: lshr <8 x i16>
+// CHECK: [[UREM:[0-9a-zA-Z%.]+]] = urem <8 x i16> {{[0-9a-zA-Z%.]+}}, 
+// CHECK: lshr <8 x i16> {{[0-9a-zA-Z%.]+}}, [[UREM]]
+// CHECK-LE: [[UREM:[0-9a-zA-Z%.]+]] = urem <8 x i16> {{[0-9a-zA-Z%.]+}}, 
+// CHECK-LE: lshr <8 x i16> {{[0-9a-zA-Z%.]+}}, [[UREM]]
 
   res_vus = vec_sr(vus, vus);
-// CHECK: lshr <8 x i16>
-// CHECK-LE: lshr <8 x i16>
+// CHECK: [[UREM:[0-9a-zA-Z%.]+]] = urem <8 x i16> {{[0-9a-zA-Z%.]+}}, 
+// CHECK: lshr <8 x i16> {{[0-9a-zA-Z%.]+}}, [[UREM]]
+// CHECK-LE: [[UREM:[0-9a-zA-Z%.]+]] = urem <8 x i16> {{[0-9a-zA-Z%.]+}}, 
+// CHECK-LE: lshr <8 x i16> {{[0-9a-zA-Z%.]+}}, [[UREM]]
 
   res_vi  = vec_sr(vi, vui);
-// CHECK: lshr <4 x i32>
-// CHECK-LE: lshr <4 x i32>
+// CHECK: [[UREM:[0-9a-zA-Z%.]+]] = urem <4 x i32> {{[0-9a-zA-Z%.]+}}, 
+// CHECK: lshr <4 x i32> {{[0-9a-zA-Z%.]+}}, [[UREM]]
+// CHECK-LE: [[UREM:[0-9a-zA-Z%.]+]] = urem <4 x i32> {{[0-9a-zA-Z%.]+}}, 
+// CHECK-LE: lshr <4 x i32> {{[0-9a-zA-Z%.]+}}, [[UREM]]
 
   res_vui = vec_sr(vui, vui);
-// CHECK: lshr <4 x i32>
-// CHECK-LE: lshr <4 x i32>
+// CHECK: [[UREM:[0-9a-zA-Z%.]+]] = urem <4 x i32> {{[0-9a-zA-Z%.]+}}, 
+// CHECK: lshr <4 x i32> {{[0-9a-zA-Z%.]+}}, [[UREM]]
+// CHECK-LE: [[UREM:[0-9a-zA-Z%.]+]] = urem <4 x i32> {{[0-9a-zA-Z%.]+}}, 
+// CHECK-LE: lshr <4 x i32> {{[0-9a-zA-Z%.]+}}, [[UREM]]
 
   res_vsc = vec_vsrb(vsc, vuc);
-// CHECK: shr <16 x i8>
-// CHECK-LE: shr <16 x i8>
+// CHECK: [[UREM:[0-9a-zA-Z%.]+]] = urem <16 x i8> {{[0-9a-zA-Z%.]+}}, 
+// CHECK: lshr <16 x i8> {{[0-9a-zA-Z%.]+}}, [[UREM]]
+// CHECK-LE: [[UREM:[0-9a-zA-Z%.]+]] = urem <16 x i8> {{[0-9a-zA-Z%.]+}}, 
+// CHECK-LE: lshr <16 x i8> {{[0-9a-zA-Z%.]+}}, [[UREM]]
 
   res_vuc = vec_vsrb(vuc, vuc);
-// CHECK: shr <16 x i8>
-// CHECK-LE: shr <16 x i8>
+// CHECK: [[UREM:[0-9a-zA-Z%.]+]] = urem <16 x i8> {{[0-9a-zA-Z%.]+}}, 
+// CHECK: lshr <16 x i8> {{[0-9a-zA-Z%.]+}}, [[UREM]]
+// CHECK-LE: [[UREM:[0-9a-zA-Z%.]+]] = urem <16 x i8> {{[0-9a-zA-Z%.]+}}, 
+// CHECK-LE: lshr <16 x i8> {{[0-9a-zA-Z%.]+}}, [[UREM]]
 
   res_vs  = vec_vsrh(vs, vus);
-// CHECK: shr <8 x i16>
-// CHECK-LE: shr <8 x i16>
+// CHECK: [[UREM:[0-9a-zA-Z%.]+]] = urem <8 x i16> {{[0-9a-zA-Z%.]+}}, 
+// CHECK: lshr <8 x i16> {{[0-9a-zA-Z%.]+}}, [[UREM]]
+// CHECK-LE: [[UREM:[0-9a-zA-Z%.]+]] = urem <8 x i16> {{[0-9a-zA-Z%.]+}}, 
+// CHECK-LE: lshr <8 x i16> {{[0-9a-zA-Z%.]+}}, [[UREM]]
 
   res_vus = vec_vsrh(vus, vus);
-// CHECK: shr <8 x i16>
-// CHECK-LE: shr <8 x i16>
+// CHECK: [[UREM:[0-9a-zA-Z%.]+]] = urem <8 x i16> {{[0-9a-zA-Z%.]+}}, 
+// CHECK: lshr <8 x i16> {{[0-9a-zA-Z%.]+}}, [[UREM]]
+// CHECK-LE: [[UREM:[0-9a-zA-Z%.]+]] = urem <8 x i16> {{[0-9a-zA-Z%.]+}}, 
+// CHECK-LE: lshr <8 x i16> {{[0-9a-zA-Z%.]+}}, [[UREM]]
 
   res_vi  = vec_vsrw(vi, vui);
-// CHECK: shr <4 x i32>
-// CHECK-LE: shr <4 x i32>
+// CHECK: [[UREM:[0-9a-zA-Z%.]+]] = urem <4 x i32> {{[0-9a-zA-Z%.]+}}, 
+// CHECK: lshr <4 x i32> {{[0-9a-zA-Z%.]+}}, [[UREM]]
+// CHECK-LE: [[UREM:[0-9a-zA-Z%.]+]] = urem <4 x i32> {{[0-9a-zA-Z%.]+}}, 
+// CHECK-LE: lshr <4 x i32> {{[0-9a-zA-Z%.]+}}, [[UREM]]
 
   res_vui = vec_vsrw(vui, vui);
-// CHECK: shr <4 x i32>
-// CHECK-LE: shr <4 x i32>
+// CHECK: [[UREM:[0-9a-zA-Z%.]+]] = urem <4 x i32> {{[0-9a-zA-Z%.]+}}, 
+// CHECK: lshr <4 x i32> {{[0-9a-zA-Z%.]+}}, [[UREM]]
+// CHECK-LE: [[UREM:[0-9a-zA-Z%.]+]] = urem <4 x i32> {{[0-9a-zA-Z%.]+}}, 
+// CHECK-LE: lshr <4 x i32> {{[0-9a-zA-Z%.]+}}, [[UREM]]
 
 

[PATCH] D53417: [Clang][Sema][PowerPC] Choose a better candidate in overload function call if there is a compatible vector conversion instead of ambiguous call error

[Zixuan Wu via Phabricator via cfe-commits]

wuzish added a comment.

In https://reviews.llvm.org/D53417#1292404, @rsmith wrote:

> I like the direction here, and I'd like to see this applied generally: a 
> conversion sequence that bitcasts a vector should be ranked worse than one 
> that does not, regardless of the kind of vector in use.


I also would like to make the direction more aggressive.


https://reviews.llvm.org/D53417



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D53417: [Clang][Sema][PowerPC] Choose a better candidate in overload function call if there is a compatible vector conversion instead of ambiguous call error

[Zixuan Wu via Phabricator via cfe-commits]

wuzish updated this revision to Diff 173276.
wuzish added a comment.

Extend the scope to all vector type as one comment suggested.

> a conversion sequence that bitcasts a vector should be ranked worse than one 
> that does not, regardless of the kind of vector in use.

Which is also made code clearly and consistently, the effect is to update some 
tests expected behavior.


https://reviews.llvm.org/D53417

Files:
  clang/lib/Sema/SemaOverload.cpp
  clang/test/CodeGen/altivec-generic-overload.c
  clang/test/Sema/altivec-generic-overload.c
  clang/test/SemaCXX/vector.cpp

Index: clang/test/SemaCXX/vector.cpp
===
--- clang/test/SemaCXX/vector.cpp
+++ clang/test/SemaCXX/vector.cpp
@@ -17,14 +17,14 @@
   f0(ll16e);
 }
 
-int &f1(char16); // expected-note 2{{candidate function}}
-float &f1(longlong16); // expected-note 2{{candidate function}}
+int &f1(char16);
+float &f1(longlong16);
 
 void f1_test(char16 c16, longlong16 ll16, char16_e c16e, longlong16_e ll16e) {
   int &ir1 = f1(c16);
   float &fr1 = f1(ll16);
-  f1(c16e); // expected-error{{call to 'f1' is ambiguous}}
-  f1(ll16e); // expected-error{{call to 'f1' is ambiguous}}
+  f1(c16e);
+  f1(ll16e);
 }
 
 void f2(char16_e); // expected-note{{no known conversion from 'longlong16_e' (vector of 2 'long long' values) to 'char16_e' (vector of 16 'char' values) for 1st argument}} \
Index: clang/test/Sema/altivec-generic-overload.c
===
--- /dev/null
+++ clang/test/Sema/altivec-generic-overload.c
@@ -0,0 +1,101 @@
+// RUN: %clang_cc1 %s -triple=powerpc64le-unknown-linux -target-feature +altivec -target-feature +vsx -verify -verify-ignore-unexpected=note -pedantic -fsyntax-only
+
+typedef signed char __v16sc __attribute__((__vector_size__(16)));
+typedef unsigned char __v16uc __attribute__((__vector_size__(16)));
+typedef signed short __v8ss __attribute__((__vector_size__(16)));
+typedef unsigned short __v8us __attribute__((__vector_size__(16)));
+typedef signed int __v4si __attribute__((__vector_size__(16)));
+typedef unsigned int __v4ui __attribute__((__vector_size__(16)));
+typedef signed long long __v2sll __attribute__((__vector_size__(16)));
+typedef unsigned long long __v2ull __attribute__((__vector_size__(16)));
+typedef signed __int128 __v1slll __attribute__((__vector_size__(16)));
+typedef unsigned __int128 __v1ulll __attribute__((__vector_size__(16)));
+typedef float __v4f __attribute__((__vector_size__(16)));
+typedef double __v2d __attribute__((__vector_size__(16)));
+
+void __attribute__((__overloadable__)) convert1(vector signed char);
+void __attribute__((__overloadable__)) convert1(vector unsigned char);
+void __attribute__((__overloadable__)) convert1(vector signed short);
+void __attribute__((__overloadable__)) convert1(vector unsigned short);
+void __attribute__((__overloadable__)) convert1(vector signed int);
+void __attribute__((__overloadable__)) convert1(vector unsigned int);
+void __attribute__((__overloadable__)) convert1(vector signed long long);
+void __attribute__((__overloadable__)) convert1(vector unsigned long long);
+void __attribute__((__overloadable__)) convert1(vector signed __int128);
+void __attribute__((__overloadable__)) convert1(vector unsigned __int128);
+void __attribute__((__overloadable__)) convert1(vector float);
+void __attribute__((__overloadable__)) convert1(vector double);
+void __attribute__((__overloadable__)) convert1(vector bool int);
+void __attribute__((__overloadable__)) convert1(vector pixel short);
+void __attribute__((__overloadable__)) convert2(__v16sc);
+void __attribute__((__overloadable__)) convert2(__v16uc);
+void __attribute__((__overloadable__)) convert2(__v8ss);
+void __attribute__((__overloadable__)) convert2(__v8us);
+void __attribute__((__overloadable__)) convert2(__v4si);
+void __attribute__((__overloadable__)) convert2(__v4ui);
+void __attribute__((__overloadable__)) convert2(__v2sll);
+void __attribute__((__overloadable__)) convert2(__v2ull);
+void __attribute__((__overloadable__)) convert2(__v1slll);
+void __attribute__((__overloadable__)) convert2(__v1ulll);
+void __attribute__((__overloadable__)) convert2(__v4f);
+void __attribute__((__overloadable__)) convert2(__v2d);
+
+void test()
+{
+  __v16sc gv1;
+  __v16uc gv2;
+  __v8ss gv3;
+  __v8us gv4;
+  __v4si gv5;
+  __v4ui gv6;
+  __v2sll gv7;
+  __v2ull gv8;
+  __v1slll gv9;
+  __v1ulll gv10;
+  __v4f gv11;
+  __v2d  gv12;
+
+  vector signed char av1;
+  vector unsigned char av2;
+  vector signed short av3;
+  vector unsigned short av4;
+  vector signed int av5;
+  vector unsigned int av6;
+  vector signed long long av7;
+  vector unsigned long long av8;
+  vector signed __int128 av9;
+  vector unsigned __int128 av10;
+  vector float av11;
+  vector double av12;
+  vector bool int av13;
+  vector pixel short av14;
+
+  convert1(gv1);
+  convert1(gv2);
+  convert1(gv3);
+  convert1(gv4);
+  convert1(gv5);
+  con

[PATCH] D53417: [Clang][Sema][PowerPC] Choose a better candidate in overload function call if there is a compatible vector conversion instead of ambiguous call error

[Zixuan Wu via Phabricator via cfe-commits]

wuzish marked 2 inline comments as done.
wuzish added a comment.

The updated patch now extended the scope and can include the case.


https://reviews.llvm.org/D53417



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D53417: [Clang][Sema][PowerPC] Choose a better candidate in overload function call if there is a compatible vector conversion instead of ambiguous call error

[Zixuan Wu via Phabricator via cfe-commits]

wuzish added inline comments.



Comment at: clang/test/CodeGen/altivec-generic-overload.c:74
+  convert1(gv1);
+  // CHECK: call void @_Z8convert1Dv16_a(<16 x i8> %{{[0-9]+}})
+  convert1(gv2);

hubert.reinterpretcast wrote:
> Checking that the call is to the expected target in terms of overload 
> resolution can be achieved by having a distinct return types for each member 
> of the overload set.
What's meaning of `having a distinct return types for each member of the 
overload set`?

Could you please give a example to show your expect?


https://reviews.llvm.org/D53417



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D53417: [Clang][Sema][PowerPC] Choose a better candidate in overload function call if there is a compatible vector conversion instead of ambiguous call error

[Zixuan Wu via Phabricator via cfe-commits]

wuzish updated this revision to Diff 173981.
wuzish added a comment.

Use return type to distinguish which overload candidate is chosen because 
different candidate has different pointer return type which can not be 
converted implicitly without reporting error.


https://reviews.llvm.org/D53417

Files:
  clang/lib/Sema/SemaOverload.cpp
  clang/test/Sema/altivec-generic-overload.c
  clang/test/SemaCXX/vector.cpp

Index: clang/test/SemaCXX/vector.cpp
===
--- clang/test/SemaCXX/vector.cpp
+++ clang/test/SemaCXX/vector.cpp
@@ -17,14 +17,14 @@
   f0(ll16e);
 }
 
-int &f1(char16); // expected-note 2{{candidate function}}
-float &f1(longlong16); // expected-note 2{{candidate function}}
+int &f1(char16);
+float &f1(longlong16);
 
 void f1_test(char16 c16, longlong16 ll16, char16_e c16e, longlong16_e ll16e) {
   int &ir1 = f1(c16);
   float &fr1 = f1(ll16);
-  f1(c16e); // expected-error{{call to 'f1' is ambiguous}}
-  f1(ll16e); // expected-error{{call to 'f1' is ambiguous}}
+  int &ir2 = f1(c16e);
+  float &fr2 = f1(ll16e);
 }
 
 void f2(char16_e); // expected-note{{no known conversion from 'longlong16_e' (vector of 2 'long long' values) to 'char16_e' (vector of 16 'char' values) for 1st argument}} \
Index: clang/test/Sema/altivec-generic-overload.c
===
--- /dev/null
+++ clang/test/Sema/altivec-generic-overload.c
@@ -0,0 +1,100 @@
+// RUN: %clang_cc1 %s -triple=powerpc64le-unknown-linux -target-feature +altivec -target-feature +vsx -verify -verify-ignore-unexpected=note -pedantic -fsyntax-only
+
+typedef signed char __v16sc __attribute__((__vector_size__(16)));
+typedef unsigned char __v16uc __attribute__((__vector_size__(16)));
+typedef signed short __v8ss __attribute__((__vector_size__(16)));
+typedef unsigned short __v8us __attribute__((__vector_size__(16)));
+typedef signed int __v4si __attribute__((__vector_size__(16)));
+typedef unsigned int __v4ui __attribute__((__vector_size__(16)));
+typedef signed long long __v2sll __attribute__((__vector_size__(16)));
+typedef unsigned long long __v2ull __attribute__((__vector_size__(16)));
+typedef signed __int128 __v1slll __attribute__((__vector_size__(16)));
+typedef unsigned __int128 __v1ulll __attribute__((__vector_size__(16)));
+typedef float __v4f __attribute__((__vector_size__(16)));
+typedef double __v2d __attribute__((__vector_size__(16)));
+
+__v16sc *__attribute__((__overloadable__)) convert1(vector signed char);
+__v16uc *__attribute__((__overloadable__)) convert1(vector unsigned char);
+__v8ss *__attribute__((__overloadable__)) convert1(vector signed short);
+__v8us *__attribute__((__overloadable__)) convert1(vector unsigned short);
+__v4si *__attribute__((__overloadable__)) convert1(vector signed int);
+__v4ui *__attribute__((__overloadable__)) convert1(vector unsigned int);
+__v2sll *__attribute__((__overloadable__)) convert1(vector signed long long);
+__v2ull *__attribute__((__overloadable__)) convert1(vector unsigned long long);
+__v1slll *__attribute__((__overloadable__)) convert1(vector signed __int128);
+__v1ulll *__attribute__((__overloadable__)) convert1(vector unsigned __int128);
+__v4f *__attribute__((__overloadable__)) convert1(vector float);
+__v2d *__attribute__((__overloadable__)) convert1(vector double);
+void __attribute__((__overloadable__)) convert1(vector bool int);
+void __attribute__((__overloadable__)) convert1(vector pixel short);
+
+vector signed char *__attribute__((__overloadable__)) convert2(__v16sc);
+vector unsigned char *__attribute__((__overloadable__)) convert2(__v16uc);
+vector signed short *__attribute__((__overloadable__)) convert2(__v8ss);
+vector unsigned short *__attribute__((__overloadable__)) convert2(__v8us);
+vector signed int *__attribute__((__overloadable__)) convert2(__v4si);
+vector unsigned int *__attribute__((__overloadable__)) convert2(__v4ui);
+vector signed long long *__attribute__((__overloadable__)) convert2(__v2sll);
+vector unsigned long long *__attribute__((__overloadable__)) convert2(__v2ull);
+vector signed __int128 *__attribute__((__overloadable__)) convert2(__v1slll);
+vector unsigned __int128 *__attribute__((__overloadable__)) convert2(__v1ulll);
+vector float *__attribute__((__overloadable__)) convert2(__v4f);
+vector double *__attribute__((__overloadable__)) convert2(__v2d);
+
+void test() {
+  __v16sc gv1;
+  __v16uc gv2;
+  __v8ss gv3;
+  __v8us gv4;
+  __v4si gv5;
+  __v4ui gv6;
+  __v2sll gv7;
+  __v2ull gv8;
+  __v1slll gv9;
+  __v1ulll gv10;
+  __v4f gv11;
+  __v2d gv12;
+
+  vector signed char av1;
+  vector unsigned char av2;
+  vector signed short av3;
+  vector unsigned short av4;
+  vector signed int av5;
+  vector unsigned int av6;
+  vector signed long long av7;
+  vector unsigned long long av8;
+  vector signed __int128 av9;
+  vector unsigned __int128 av10;
+  vector float av11;
+  vector double av12;
+  vector bool int av13;
+  vector pixel short av1

[PATCH] D53417: [Clang][Sema][PowerPC] Choose a better candidate in overload function call if there is a compatible vector conversion instead of ambiguous call error

[Zixuan Wu via Phabricator via cfe-commits]

wuzish marked an inline comment as done.
wuzish added inline comments.



Comment at: clang/test/SemaCXX/vector.cpp:26
   float &fr1 = f1(ll16);
-  f1(c16e); // expected-error{{call to 'f1' is ambiguous}}
-  f1(ll16e); // expected-error{{call to 'f1' is ambiguous}}
+  f1(c16e);
+  f1(ll16e);

hubert.reinterpretcast wrote:
> Check the return types here like with the two lines above.
I use pointer or reference return value to distinguish the candidate.


https://reviews.llvm.org/D53417



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D53417: [Clang][Sema]Choose a better candidate in overload function call if there is a compatible vector conversion instead of ambiguous call error

[Zixuan Wu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
wuzish marked an inline comment as done.
Closed by commit rC347019: [Clang][Sema]Choose a better candidate in overload 
function call if there is a… (authored by wuzish, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D53417?vs=173981&id=174315#toc

Repository:
  rC Clang

https://reviews.llvm.org/D53417

Files:
  lib/Sema/SemaOverload.cpp
  test/Sema/altivec-generic-overload.c
  test/SemaCXX/vector.cpp

Index: lib/Sema/SemaOverload.cpp
===
--- lib/Sema/SemaOverload.cpp
+++ lib/Sema/SemaOverload.cpp
@@ -3900,6 +3900,31 @@
   S.Context.getTypeSize(SCS1.getToType(2)))
 return ImplicitConversionSequence::Better;
 
+  // Prefer a compatible vector conversion over a lax vector conversion
+  // For example:
+  //
+  // typedef float __v4sf __attribute__((__vector_size__(16)));
+  // void f(vector float);
+  // void f(vector signed int);
+  // int main() {
+  //   __v4sf a;
+  //   f(a);
+  // }
+  // Here, we'd like to choose f(vector float) and not
+  // report an ambiguous call error
+  if (SCS1.Second == ICK_Vector_Conversion &&
+  SCS2.Second == ICK_Vector_Conversion) {
+bool SCS1IsCompatibleVectorConversion = S.Context.areCompatibleVectorTypes(
+SCS1.getFromType(), SCS1.getToType(2));
+bool SCS2IsCompatibleVectorConversion = S.Context.areCompatibleVectorTypes(
+SCS2.getFromType(), SCS2.getToType(2));
+
+if (SCS1IsCompatibleVectorConversion != SCS2IsCompatibleVectorConversion)
+  return SCS1IsCompatibleVectorConversion
+ ? ImplicitConversionSequence::Better
+ : ImplicitConversionSequence::Worse;
+  }
+
   return ImplicitConversionSequence::Indistinguishable;
 }
 
Index: test/SemaCXX/vector.cpp
===
--- test/SemaCXX/vector.cpp
+++ test/SemaCXX/vector.cpp
@@ -17,14 +17,14 @@
   f0(ll16e);
 }
 
-int &f1(char16); // expected-note 2{{candidate function}}
-float &f1(longlong16); // expected-note 2{{candidate function}}
+int &f1(char16);
+float &f1(longlong16);
 
 void f1_test(char16 c16, longlong16 ll16, char16_e c16e, longlong16_e ll16e) {
   int &ir1 = f1(c16);
   float &fr1 = f1(ll16);
-  f1(c16e); // expected-error{{call to 'f1' is ambiguous}}
-  f1(ll16e); // expected-error{{call to 'f1' is ambiguous}}
+  int &ir2 = f1(c16e);
+  float &fr2 = f1(ll16e);
 }
 
 void f2(char16_e); // expected-note{{no known conversion from 'longlong16_e' (vector of 2 'long long' values) to 'char16_e' (vector of 16 'char' values) for 1st argument}} \
Index: test/Sema/altivec-generic-overload.c
===
--- test/Sema/altivec-generic-overload.c
+++ test/Sema/altivec-generic-overload.c
@@ -0,0 +1,100 @@
+// RUN: %clang_cc1 %s -triple=powerpc64le-unknown-linux -target-feature +altivec -target-feature +vsx -verify -verify-ignore-unexpected=note -pedantic -fsyntax-only
+
+typedef signed char __v16sc __attribute__((__vector_size__(16)));
+typedef unsigned char __v16uc __attribute__((__vector_size__(16)));
+typedef signed short __v8ss __attribute__((__vector_size__(16)));
+typedef unsigned short __v8us __attribute__((__vector_size__(16)));
+typedef signed int __v4si __attribute__((__vector_size__(16)));
+typedef unsigned int __v4ui __attribute__((__vector_size__(16)));
+typedef signed long long __v2sll __attribute__((__vector_size__(16)));
+typedef unsigned long long __v2ull __attribute__((__vector_size__(16)));
+typedef signed __int128 __v1slll __attribute__((__vector_size__(16)));
+typedef unsigned __int128 __v1ulll __attribute__((__vector_size__(16)));
+typedef float __v4f __attribute__((__vector_size__(16)));
+typedef double __v2d __attribute__((__vector_size__(16)));
+
+__v16sc *__attribute__((__overloadable__)) convert1(vector signed char);
+__v16uc *__attribute__((__overloadable__)) convert1(vector unsigned char);
+__v8ss *__attribute__((__overloadable__)) convert1(vector signed short);
+__v8us *__attribute__((__overloadable__)) convert1(vector unsigned short);
+__v4si *__attribute__((__overloadable__)) convert1(vector signed int);
+__v4ui *__attribute__((__overloadable__)) convert1(vector unsigned int);
+__v2sll *__attribute__((__overloadable__)) convert1(vector signed long long);
+__v2ull *__attribute__((__overloadable__)) convert1(vector unsigned long long);
+__v1slll *__attribute__((__overloadable__)) convert1(vector signed __int128);
+__v1ulll *__attribute__((__overloadable__)) convert1(vector unsigned __int128);
+__v4f *__attribute__((__overloadable__)) convert1(vector float);
+__v2d *__attribute__((__overloadable__)) convert1(vector double);
+void __attribute__((__overloadable__)) convert1(vector bool int);
+void __attribute__((__overloadable__)) convert1(vector pixel short);
+
+vector signed char *__attribute__((__overloadable__)) convert2(__v16sc);
+vector unsigned cha

[PATCH] D52074: [PowerPC] [Clang] Add vector int128 pack/unpack builtins

[Zixuan Wu via Phabricator via cfe-commits]

wuzish added a comment.
Herald added a subscriber: jsji.

Please help me to commit this patch. Thanks a lot.


Repository:
  rC Clang

https://reviews.llvm.org/D52074



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[Diffusion] rL358949: [PowerPC] [Clang] Port MMX intrinsics and basic test cases to Power

[Zixuan Wu via Phabricator via cfe-commits]

wuzish added inline comments.

/cfe/trunk/lib/Driver/ToolChains/PPCLinux.cpp:26 @hubert.reinterpretcast 
Thanks for your advice. I think the name `ppc_wrappers` is accurate to describe 
its meaning that wrapping the headers under standard library path or standard 
header search path. (Headers in lib/Headers is clang standard search path) It's 
truly that `ppc_wrappers` can be used for all platforms of powerpc no matter 
what's OS or bit mode or endian because there are only little num of files and 
no need for too many level directory. And we can distinguish OS, endian or mode 
by macros in wrapped headers, combining with `#include_next` as what you said, 
which I also prefer to use because it's easier to maintain headers instead of 
modifying cpp code about toolchain class such as `PPCLinuxToolChain `.

We will use better way described above to guard those headers only in 64-bit 
mode soon after other headers have been upstreamed.

https://reviews.llvm.org/rL358949



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[Diffusion] rL358949: [PowerPC] [Clang] Port MMX intrinsics and basic test cases to Power

[Zixuan Wu via Phabricator via cfe-commits]

wuzish added a comment.

> That (controlling within the headers) sounds good to me. When that lands, 
> then my understanding is that the `PPCLinuxToolChain` code would be adjusted 
> to include `ppc_wrappers` in the search path in the general case. Please let 
> me know if that's not the case. Thanks.

Yes, I 'd like to include `ppc_wrappers` in the search path directly not 
conditionally later.


https://reviews.llvm.org/rL358949



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D62121: [PowerPC] [Clang] Port SSE intrinsics to PowerPC

[Zixuan Wu via Phabricator via cfe-commits]

wuzish added a comment.

Thanks. I will commit for @qiucf


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62121/new/

https://reviews.llvm.org/D62121



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D122160: [clang][extract-api] Refactor ExtractAPI and improve docs

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp:159
+  switch (Language) {
+  case Language::C:
+return "c";

It's same name as `Language` variable above, and it cause compile error. @zixuw 
Maybe the error depends on host compiler version so that it does not report 
immediately.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D122160/new/

https://reviews.llvm.org/D122160

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D122089: [CUDA] Add getTargetFeatures for the NVPTX toolchain

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: clang/lib/Driver/ToolChains/Cuda.cpp:648
+#define CASE_CUDA_VERSION(CUDA_VER, PTX_VER)   
\
+  case CudaVersion::CUDA_##CUDA_VER:   
\
+PtxFeature = "+ptx" #PTX_VER;  
\

It's same name as `CudaVersion` variable above, and it cause compile error. 
@jhuber6 
Maybe the error depends on host compiler version so that it does not report 
immediately.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D122089/new/

https://reviews.llvm.org/D122089

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D122089: [CUDA] Add getTargetFeatures for the NVPTX toolchain

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: clang/lib/Driver/ToolChains/Cuda.cpp:648
+#define CASE_CUDA_VERSION(CUDA_VER, PTX_VER)   
\
+  case CudaVersion::CUDA_##CUDA_VER:   
\
+PtxFeature = "+ptx" #PTX_VER;  
\

jhuber6 wrote:
> zixuan-wu wrote:
> > It's same name as `CudaVersion` variable above, and it cause compile error. 
> > @jhuber6 
> > Maybe the error depends on host compiler version so that it does not report 
> > immediately.
> Fixed in rGd91223274145. Thanks for pointing that out, it worked fined 
> locally.
Thank you for your quick action.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D122089/new/

https://reviews.llvm.org/D122089

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D121445: [Clang][CSKY] Add the CSKY target and compiler driver

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu updated this revision to Diff 419076.
zixuan-wu added a comment.
Herald added subscribers: StephenFan, dexonsmith, MaskRay.

Address comments.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D121445/new/

https://reviews.llvm.org/D121445

Files:
  clang/lib/Basic/CMakeLists.txt
  clang/lib/Basic/Targets.cpp
  clang/lib/Basic/Targets/CSKY.cpp
  clang/lib/Basic/Targets/CSKY.h
  clang/lib/Driver/CMakeLists.txt
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/Arch/CSKY.cpp
  clang/lib/Driver/ToolChains/Arch/CSKY.h
  clang/lib/Driver/ToolChains/CSKYToolChain.cpp
  clang/lib/Driver/ToolChains/CSKYToolChain.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/lib/Driver/ToolChains/Linux.cpp
  clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/bin/ld
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/libc/ck860v/lib/.keep
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/libc/ck860v/usr/lib/crt1.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/libc/lib/.keep
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/libc/usr/lib/crt1.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/ck860v/crtbegin.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/ck860v/crtend.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/ck860v/crti.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/ck860v/crtn.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/crtbegin.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/crtend.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/crti.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/crtn.o
  clang/test/Driver/csky-arch-error.c
  clang/test/Driver/csky-arch.c
  clang/test/Driver/csky-cpus-error.c
  clang/test/Driver/csky-cpus.c
  clang/test/Driver/csky-toolchain.c
  clang/test/Preprocessor/csky-target-features.c
  clang/test/Preprocessor/init-csky.c
  llvm/lib/Support/CSKYTargetParser.cpp
  llvm/unittests/Support/CSKYTargetParserTest.cpp

Index: llvm/unittests/Support/CSKYTargetParserTest.cpp
===
--- llvm/unittests/Support/CSKYTargetParserTest.cpp
+++ llvm/unittests/Support/CSKYTargetParserTest.cpp
@@ -1061,18 +1061,11 @@
   EXPECT_FALSE(CSKY::getExtensionFeatures(CSKY::AEK_INVALID, Features));
 
   for (auto &E : Extensions) {
-// test +extension
-Features.clear();
 CSKY::getExtensionFeatures(E.first, Features);
 EXPECT_TRUE(llvm::is_contained(Features, E.second.at(0)));
-EXPECT_EQ(Extensions.size(), Features.size());
-
-// test -extension
-Features.clear();
-CSKY::getExtensionFeatures(~E.first, Features);
-EXPECT_TRUE(llvm::is_contained(Features, E.second.at(1)));
-EXPECT_EQ(Extensions.size(), Features.size());
   }
+
+  EXPECT_EQ(Extensions.size(), Features.size());
 }
 
 TEST(TargetParserTest, CSKYFPUFeatures) {
Index: llvm/lib/Support/CSKYTargetParser.cpp
===
--- llvm/lib/Support/CSKYTargetParser.cpp
+++ llvm/lib/Support/CSKYTargetParser.cpp
@@ -172,8 +172,6 @@
   for (const auto &AE : CSKYARCHExtNames) {
 if ((Extensions & AE.ID) == AE.ID && AE.Feature)
   Features.push_back(AE.Feature);
-else if (AE.NegFeature)
-  Features.push_back(AE.NegFeature);
   }
 
   return true;
Index: clang/test/Preprocessor/init-csky.c
===
--- /dev/null
+++ clang/test/Preprocessor/init-csky.c
@@ -0,0 +1,211 @@
+// RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 -triple=csky < /dev/null \
+// RUN:   | FileCheck -match-full-lines -check-prefix=CSKY %s
+// RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 -triple=csky-unknown-linux < /dev/null \
+// RUN:   | FileCheck -match-full-lines -check-prefixes=CSKY,CSKY-LINUX %s
+// RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 -triple=csky \
+// RUN: -fforce-enable-int128 < /dev/null | FileCheck -match-full-lines \
+// RUN: -check-prefixes=CSKY,CSKY-INT128 %s
+// CSKY: #define _ILP32 1
+// CSKY: #define __ATOMIC_ACQUIRE 2
+// CSKY: #define __ATOMIC_ACQ_REL 4
+// CSKY: #define __ATOMIC_CONSUME 1
+// CSKY: #define __ATOMIC_RELAXED 0
+// CSKY: #define __ATOMIC_RELEASE 3
+// CSKY: #define __ATOMIC_SEQ_CST 5
+// CSKY: #define __BIGGEST_ALIGNMENT__ 4
+// CSKY: #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
+// CSKY: #define __CHAR16_TYPE__ unsigned short
+// CSKY: #define __CHAR32_TYPE__ unsigned int
+// CSKY: #define __CHAR_BIT__ 8
+// CSKY: #define __DBL_DECIMAL_DIG__ 17
+// CSKY: #define __DBL_DENORM_

[PATCH] D121445: [Clang][CSKY] Add the CSKY target and compiler driver

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D121445#3416518 , @rengolin wrote:

> There is also a test error:
>
>    TEST 'Clang :: Driver/csky-toolchain.c' FAILED 
> 
>   ...
>   /home/rengolin/devel/llvm-project/clang/test/Driver/csky-toolchain.c:16:24: 
> error: C-CSKY-LINUX-MULTI: expected string not found in input
>   // C-CSKY-LINUX-MULTI: 
> "{{.*}}/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/../../..{{/|}}..{{/|}}csky-linux-gnuabiv2/bin{{/|}}ld"
>   
>  ^
>
> I'm guessing this is the path of a local sysroot you have on your machine?
>
> If possible, try to get a new environment (container, VM, alternative 
> machine) and make sure a clean build still passes the tests.

I have met this before because the downloading of patch will ignore empty 
files. You can have a check that your apply does not contain new empty files in 
multilib_csky_linux_sdk.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D121445/new/

https://reviews.llvm.org/D121445

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D121445: [Clang][CSKY] Add the CSKY target and compiler driver

[Zixuan Wu via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG97e496054a37: [Clang][CSKY] Add the CSKY target and compiler 
driver (authored by zixuan-wu).

Changed prior to commit:
  https://reviews.llvm.org/D121445?vs=419076&id=420697#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D121445/new/

https://reviews.llvm.org/D121445

Files:
  clang/lib/Basic/CMakeLists.txt
  clang/lib/Basic/Targets.cpp
  clang/lib/Basic/Targets/CSKY.cpp
  clang/lib/Basic/Targets/CSKY.h
  clang/lib/Driver/CMakeLists.txt
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/Arch/CSKY.cpp
  clang/lib/Driver/ToolChains/Arch/CSKY.h
  clang/lib/Driver/ToolChains/CSKYToolChain.cpp
  clang/lib/Driver/ToolChains/CSKYToolChain.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/lib/Driver/ToolChains/Linux.cpp
  clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/bin/ld
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/libc/ck860v/lib/.keep
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/libc/ck860v/usr/lib/crt1.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/libc/lib/.keep
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/libc/usr/lib/crt1.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/ck860v/crtbegin.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/ck860v/crtend.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/ck860v/crti.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/ck860v/crtn.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/crtbegin.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/crtend.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/crti.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/crtn.o
  clang/test/Driver/csky-arch-error.c
  clang/test/Driver/csky-arch.c
  clang/test/Driver/csky-cpus-error.c
  clang/test/Driver/csky-cpus.c
  clang/test/Driver/csky-toolchain.c
  clang/test/Preprocessor/csky-target-features.c
  clang/test/Preprocessor/init-csky.c
  llvm/lib/Support/CSKYTargetParser.cpp
  llvm/unittests/Support/CSKYTargetParserTest.cpp

Index: llvm/unittests/Support/CSKYTargetParserTest.cpp
===
--- llvm/unittests/Support/CSKYTargetParserTest.cpp
+++ llvm/unittests/Support/CSKYTargetParserTest.cpp
@@ -1061,18 +1061,11 @@
   EXPECT_FALSE(CSKY::getExtensionFeatures(CSKY::AEK_INVALID, Features));
 
   for (auto &E : Extensions) {
-// test +extension
-Features.clear();
 CSKY::getExtensionFeatures(E.first, Features);
 EXPECT_TRUE(llvm::is_contained(Features, E.second.at(0)));
-EXPECT_EQ(Extensions.size(), Features.size());
-
-// test -extension
-Features.clear();
-CSKY::getExtensionFeatures(~E.first, Features);
-EXPECT_TRUE(llvm::is_contained(Features, E.second.at(1)));
-EXPECT_EQ(Extensions.size(), Features.size());
   }
+
+  EXPECT_EQ(Extensions.size(), Features.size());
 }
 
 TEST(TargetParserTest, CSKYFPUFeatures) {
Index: llvm/lib/Support/CSKYTargetParser.cpp
===
--- llvm/lib/Support/CSKYTargetParser.cpp
+++ llvm/lib/Support/CSKYTargetParser.cpp
@@ -172,8 +172,6 @@
   for (const auto &AE : CSKYARCHExtNames) {
 if ((Extensions & AE.ID) == AE.ID && AE.Feature)
   Features.push_back(AE.Feature);
-else if (AE.NegFeature)
-  Features.push_back(AE.NegFeature);
   }
 
   return true;
Index: clang/test/Preprocessor/init-csky.c
===
--- /dev/null
+++ clang/test/Preprocessor/init-csky.c
@@ -0,0 +1,211 @@
+// RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 -triple=csky < /dev/null \
+// RUN:   | FileCheck -match-full-lines -check-prefix=CSKY %s
+// RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 -triple=csky-unknown-linux < /dev/null \
+// RUN:   | FileCheck -match-full-lines -check-prefixes=CSKY,CSKY-LINUX %s
+// RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 -triple=csky \
+// RUN: -fforce-enable-int128 < /dev/null | FileCheck -match-full-lines \
+// RUN: -check-prefixes=CSKY,CSKY-INT128 %s
+// CSKY: #define _ILP32 1
+// CSKY: #define __ATOMIC_ACQUIRE 2
+// CSKY: #define __ATOMIC_ACQ_REL 4
+// CSKY: #define __ATOMIC_CONSUME 1
+// CSKY: #define __ATOMIC_RELAXED 0
+// CSKY: #define __ATOMIC_RELEASE 3
+// CSKY: #define __ATOMIC_SEQ_CST 5
+// CSKY: #define __BIGGEST_ALIGNMENT__ 4
+// CSKY: #define __BYTE_ORDER__ __ORDER_LITT

[PATCH] D121445: [Clang][CSKY] Add the CSKY target and compiler driver

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D121445#3431569 , @dyung wrote:

> Hi, one of the tests you added. csky-toolchain.c seems to be failing on a 
> Windows build bot, and from a quick look, it appears to be a path separator 
> issue. Can you take a look?
>
> https://lab.llvm.org/buildbot/#/builders/216/builds/2452

Reference to other target toolchain case, it should add unsupported directive. 
Fixed it at https://reviews.llvm.org/rG9906d38252d112894f304ba1b4fbdcd2cc93ab19


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D121445/new/

https://reviews.llvm.org/D121445

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D93138: Add initial support for multilibs in Baremetal toolchain.

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.
Herald added subscribers: pcwang-thead, luke957, StephenFan, MaskRay, 
arichardson.
Herald added a project: All.



Comment at: clang/lib/Driver/ToolChains/BareMetal.cpp:177
   if (!getDriver().SysRoot.empty())
-return getDriver().SysRoot;
+return getDriver().SysRoot + SelectedMultilib.osSuffix();
 

I think the multilib osSuffix added here will make every multilib contain 
include dir, and those include dirs are the same. For lib, there should be 
different multilib dir. 

So it's better to add osSuffix at construction function like following I think 
instead of be part of sysroot.

```
if (!SysRoot.empty()) {
llvm::sys::path::append(SysRoot, "lib", SelectedMultilib.osSuffix());
getFilePaths().push_back(std::string(SysRoot));
  }
```

@abidh 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93138/new/

https://reviews.llvm.org/D93138

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D93138: Add initial support for multilibs in Baremetal toolchain.

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: clang/lib/Driver/ToolChains/BareMetal.cpp:177
   if (!getDriver().SysRoot.empty())
-return getDriver().SysRoot;
+return getDriver().SysRoot + SelectedMultilib.osSuffix();
 

abidh wrote:
> zixuan-wu wrote:
> > I think the multilib osSuffix added here will make every multilib contain 
> > include dir, and those include dirs are the same. For lib, there should be 
> > different multilib dir. 
> > 
> > So it's better to add osSuffix at construction function like following I 
> > think instead of be part of sysroot.
> > 
> > ```
> > if (!SysRoot.empty()) {
> > llvm::sys::path::append(SysRoot, "lib", SelectedMultilib.osSuffix());
> > getFilePaths().push_back(std::string(SysRoot));
> >   }
> > ```
> > 
> > @abidh 
> The multilib include directories are not necessarily the same.  In my 
> opinion, having a separate include and lib directory for every multilib is 
> much cleaner then having all multilib share an include directory and then you 
> put multilib specific directories inside that.
So you are going to copy times of same include headers? For now,  GCC on RISCV 
is just sharing one same include directory and having multiple multilib 
directory under lib of root.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93138/new/

https://reviews.llvm.org/D93138

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D63329: Allow static linking of libc++ on Linux, just like -static-libstdc++

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.
Herald added a subscriber: MaskRay.
Herald added a project: All.

Is this going to continue?
And also if we use libunwind to handle EH, then it uses dladdr function which 
need link libdl.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63329/new/

https://reviews.llvm.org/D63329

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D129824: [RISCV] Set triple based on -march flag which can be deduced in more generic way

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D129824#3699911 , @kito-cheng 
wrote:

> Just realized the problem is trying to fixed the default value of `-mabi=`, 
> currently `clang -target riscv32-elf -march=rv64gc 
> -mabi=lp64d`/`riscv32-elf-clang -march=rv64gc -mabi=lp64d` is work, and match 
> the behavior of GCC did, `riscv32-elf-gcc -march=rv64gc -mabi=lp64d`.
>
> And this patch is trying to make following two command work: `clang -target 
> riscv32-elf -march=rv64gc`/`riscv32-elf-clang -march=rv64gc`, specify 
> `-march` and `-target` but no `-mabi`.
>
> That is different story now, GCC isn't deduce the default abi from either 
> target triple or abi, so if you invoke gcc with `riscv32-elf-gcc 
> -march=rv64gc` or `riscv64-elf-gcc -march=rv32gc`, you will got error message 
> like that: `cc1: error: ABI requires '-march=rv32'` or `cc1: error: ABI 
> requires '-march=rv64'`.
>
> So that's not compatible issue with GCC, that's sort of clang driver specify 
> issue, and I don't have strong opinion on this.
>
> ---
>
> As a GNU toolchain developer, I would say, we are not intend to change the 
> behavior of default value of `-mabi` or `-march`, the consensus among RISC-V 
> GNU toolchain maintainer is user should explicitly specify the `-march` and 
> `-mabi` if you are not using default `-march` and `-mabi`.

This patch is not about default value of mabi. It just tries to deduce march 
when -march option is not provided explicitly. 
It fixes the conflict between target triple and march about 32-bit/64-bit 
(riscv32 or riscv64) issue as before. Before this patch, this conflict only can 
be solved by specifying -march option explicitly.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129824/new/

https://reviews.llvm.org/D129824

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D129824: [RISCV] Set triple based on -march flag which can be deduced in more generic way

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D129824#3706654 , @asb wrote:

> @zixuan-wu we discussed this a bit in the last community sync call 
> .
>  One aspect that makes this patch a little hard to review is the lack of a 
> clear patch description summarising the behaviour before the patch, the 
> behaviour after the patch, and the motivation for the change. I appreciate 
> that the time isn't very convenient in all timezones, but if you were able to 
> attend the next call (18th August, same time) to discuss, that might really 
> help agree a path forwards on this change.

I updated the description. I think it can be understood after see D54214 
.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129824/new/

https://reviews.llvm.org/D129824

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D129824: [RISCV] Set triple based on -march flag which can be deduced in more generic way

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: clang/test/Driver/riscv-arch.c:410
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-TARGET %s
+// RUN: %clang --target=riscv32-unknown-elf -mcpu=sifive-s21 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-TARGET %s

jrtc27 wrote:
> This one maybe makes sense to allow, though gets murky once you have cores 
> that support writable XLEN as then the same CPU exists for both RV32 and RV64 
> (like how you can ask for say haswell i386 and x86_64) so I'm not entirely 
> sure...
For now, if the name of sifive-s21 can't be both RV32 and RV64. It must 
distinguish the name in RISCVTargetParser.def.



Comment at: clang/test/Driver/riscv-arch.c:414
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-TARGET %s
+// RUN: %clang --target=riscv32-unknown-elf -mabi=lp64 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-TARGET %s

jrtc27 wrote:
> IMO this kind of thing should remain an error, you're asking for an ABI that 
> doesn't exist for the requested architecture
IMO, if -march is accepted to override riscv32 target triple, and march can get 
by `riscv::getRISCVArch` function with -mabi, then it should also accept. Or 
`riscv::getRISCVArch` should not get -march from -mabi.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129824/new/

https://reviews.llvm.org/D129824

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D121445: [Clang][CSKY] Add the CSKY target and compiler driver

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu created this revision.
zixuan-wu added reviewers: rengolin, kito.cheng, rsmith, asb, DavidSpickett, 
kaz7.
Herald added subscribers: krytarowski, mgorny.
Herald added a project: All.
zixuan-wu requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Add CSKY target toolchains to support csky in linux and elf environment.

It can leverage the basic universal Linux toolchain for linux environment, and 
only add some compile or link parameters. For elf environment, add a 
CSKYToolChain to support compile and link.

Also add some parameters into basic codebase of clang driver.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D121445

Files:
  clang/lib/Basic/CMakeLists.txt
  clang/lib/Basic/Targets.cpp
  clang/lib/Basic/Targets/CSKY.cpp
  clang/lib/Basic/Targets/CSKY.h
  clang/lib/Driver/CMakeLists.txt
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/Arch/CSKY.cpp
  clang/lib/Driver/ToolChains/Arch/CSKY.h
  clang/lib/Driver/ToolChains/CSKYToolChain.cpp
  clang/lib/Driver/ToolChains/CSKYToolChain.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/lib/Driver/ToolChains/Linux.cpp
  clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/bin/ld
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/libc/ck860v/lib/.keep
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/libc/ck860v/usr/lib/crt1.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/libc/lib/.keep
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/libc/usr/lib/crt1.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/ck860v/crtbegin.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/ck860v/crtend.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/ck860v/crti.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/ck860v/crtn.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/crtbegin.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/crtend.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/crti.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/crtn.o
  clang/test/Driver/csky-arch.c
  clang/test/Driver/csky-cpus.c
  clang/test/Driver/csky-toolchain.c
  clang/test/Preprocessor/csky-target-features.c
  clang/test/Preprocessor/init-csky.c

Index: clang/test/Preprocessor/init-csky.c
===
--- /dev/null
+++ clang/test/Preprocessor/init-csky.c
@@ -0,0 +1,212 @@
+// RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 -triple=csky < /dev/null \
+// RUN:   | FileCheck -match-full-lines -check-prefix=CSKY %s
+// RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 -triple=csky-unknown-linux < /dev/null \
+// RUN:   | FileCheck -match-full-lines -check-prefixes=CSKY,CSKY-LINUX %s
+// RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 -triple=csky \
+// RUN: -fforce-enable-int128 < /dev/null | FileCheck -match-full-lines \
+// RUN: -check-prefixes=CSKY,CSKY-INT128 %s
+// CSKY: #define _ILP32 1
+// CSKY: #define __ATOMIC_ACQUIRE 2
+// CSKY: #define __ATOMIC_ACQ_REL 4
+// CSKY: #define __ATOMIC_CONSUME 1
+// CSKY: #define __ATOMIC_RELAXED 0
+// CSKY: #define __ATOMIC_RELEASE 3
+// CSKY: #define __ATOMIC_SEQ_CST 5
+// CSKY: #define __BIGGEST_ALIGNMENT__ 4
+// CSKY: #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
+// CSKY: #define __CHAR16_TYPE__ unsigned short
+// CSKY: #define __CHAR32_TYPE__ unsigned int
+// CSKY: #define __CHAR_BIT__ 8
+// CSKY: #define __DBL_DECIMAL_DIG__ 17
+// CSKY: #define __DBL_DENORM_MIN__ 4.9406564584124654e-324
+// CSKY: #define __DBL_DIG__ 15
+// CSKY: #define __DBL_EPSILON__ 2.2204460492503131e-16
+// CSKY: #define __DBL_HAS_DENORM__ 1
+// CSKY: #define __DBL_HAS_INFINITY__ 1
+// CSKY: #define __DBL_HAS_QUIET_NAN__ 1
+// CSKY: #define __DBL_MANT_DIG__ 53
+// CSKY: #define __DBL_MAX_10_EXP__ 308
+// CSKY: #define __DBL_MAX_EXP__ 1024
+// CSKY: #define __DBL_MAX__ 1.7976931348623157e+308
+// CSKY: #define __DBL_MIN_10_EXP__ (-307)
+// CSKY: #define __DBL_MIN_EXP__ (-1021)
+// CSKY: #define __DBL_MIN__ 2.2250738585072014e-308
+// CSKY: #define __DECIMAL_DIG__ __LDBL_DECIMAL_DIG__
+// CSKY: #define __ELF__ 1
+// CSKY: #define __FINITE_MATH_ONLY__ 0
+// CSKY: #define __FLT_DECIMAL_DIG__ 9
+// CSKY: #define __FLT_DENORM_MIN__ 1.40129846e-45F
+// CSKY: #define __FLT_DIG__ 6
+// CSKY: #define __FLT_EPSILON__ 1.19209290e-7F
+// CSKY: #define __FLT_HAS_DENORM__ 1
+// CSKY: #define __FLT_HAS_INFINITY__ 1
+// CSKY: #define __FLT_HAS_QUIET_NAN__ 1
+// CSKY: #define __FLT_MANT_DIG__ 24
+// CSKY: #define __FLT_MAX_10_EXP__ 38
+

[PATCH] D121445: [Clang][CSKY] Add the CSKY target and compiler driver

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: clang/lib/Basic/Targets/CSKY.cpp:43
+  Builder.defineMacro("__CSKYABI__", ABI == "abiv2" ? "2" : "1");
+  Builder.defineMacro("__cskyabi__", ABI == "abiv2" ? "2" : "1");
+

DavidSpickett wrote:
> Any need to handle when ABI is not avbiv2 or abiv1 or will it always be one 
> of the two?
Yes. It always be one of the two.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D121445/new/

https://reviews.llvm.org/D121445

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D121445: [Clang][CSKY] Add the CSKY target and compiler driver

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: clang/test/Driver/csky-arch.c:26
+
+// RUN: %clang -target csky-unknown-elf -march=csky -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=CSKY %s

rengolin wrote:
> I don't think this is doing what you expect it to do.
> 
> Depending on the output, you can still match all CHECK lines and not have the 
> output you want.
> 
> To avoid issues, we usually separate tests that must pass (positive tests) 
> like the lines above 24, from tests that must fail (negative tests) like the 
> lines below.
You mean separate into two files or two parts in one file?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D121445/new/

https://reviews.llvm.org/D121445

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D121445: [Clang][CSKY] Add the CSKY target and compiler driver

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu updated this revision to Diff 415006.
zixuan-wu added a comment.
Herald added subscribers: llvm-commits, hiraditya.
Herald added a project: LLVM.

Address comments.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D121445/new/

https://reviews.llvm.org/D121445

Files:
  clang/lib/Basic/CMakeLists.txt
  clang/lib/Basic/Targets.cpp
  clang/lib/Basic/Targets/CSKY.cpp
  clang/lib/Basic/Targets/CSKY.h
  clang/lib/Driver/CMakeLists.txt
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/Arch/CSKY.cpp
  clang/lib/Driver/ToolChains/Arch/CSKY.h
  clang/lib/Driver/ToolChains/CSKYToolChain.cpp
  clang/lib/Driver/ToolChains/CSKYToolChain.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/lib/Driver/ToolChains/Linux.cpp
  clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/bin/ld
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/libc/ck860v/lib/.keep
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/libc/ck860v/usr/lib/crt1.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/libc/lib/.keep
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/libc/usr/lib/crt1.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/ck860v/crtbegin.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/ck860v/crtend.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/ck860v/crti.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/ck860v/crtn.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/crtbegin.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/crtend.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/crti.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/crtn.o
  clang/test/Driver/csky-arch-error.c
  clang/test/Driver/csky-arch.c
  clang/test/Driver/csky-cpus.c
  clang/test/Driver/csky-toolchain.c
  clang/test/Preprocessor/csky-target-features.c
  clang/test/Preprocessor/init-csky.c
  llvm/lib/Target/CSKY/CSKY.h

Index: llvm/lib/Target/CSKY/CSKY.h
===
--- llvm/lib/Target/CSKY/CSKY.h
+++ llvm/lib/Target/CSKY/CSKY.h
@@ -19,6 +19,7 @@
 namespace llvm {
 class CSKYTargetMachine;
 class FunctionPass;
+class PassRegistry;
 
 FunctionPass *createCSKYISelDag(CSKYTargetMachine &TM);
 FunctionPass *createCSKYConstantIslandPass();
Index: clang/test/Preprocessor/init-csky.c
===
--- /dev/null
+++ clang/test/Preprocessor/init-csky.c
@@ -0,0 +1,212 @@
+// RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 -triple=csky < /dev/null \
+// RUN:   | FileCheck -match-full-lines -check-prefix=CSKY %s
+// RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 -triple=csky-unknown-linux < /dev/null \
+// RUN:   | FileCheck -match-full-lines -check-prefixes=CSKY,CSKY-LINUX %s
+// RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 -triple=csky \
+// RUN: -fforce-enable-int128 < /dev/null | FileCheck -match-full-lines \
+// RUN: -check-prefixes=CSKY,CSKY-INT128 %s
+// CSKY: #define _ILP32 1
+// CSKY: #define __ATOMIC_ACQUIRE 2
+// CSKY: #define __ATOMIC_ACQ_REL 4
+// CSKY: #define __ATOMIC_CONSUME 1
+// CSKY: #define __ATOMIC_RELAXED 0
+// CSKY: #define __ATOMIC_RELEASE 3
+// CSKY: #define __ATOMIC_SEQ_CST 5
+// CSKY: #define __BIGGEST_ALIGNMENT__ 4
+// CSKY: #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
+// CSKY: #define __CHAR16_TYPE__ unsigned short
+// CSKY: #define __CHAR32_TYPE__ unsigned int
+// CSKY: #define __CHAR_BIT__ 8
+// CSKY: #define __DBL_DECIMAL_DIG__ 17
+// CSKY: #define __DBL_DENORM_MIN__ 4.9406564584124654e-324
+// CSKY: #define __DBL_DIG__ 15
+// CSKY: #define __DBL_EPSILON__ 2.2204460492503131e-16
+// CSKY: #define __DBL_HAS_DENORM__ 1
+// CSKY: #define __DBL_HAS_INFINITY__ 1
+// CSKY: #define __DBL_HAS_QUIET_NAN__ 1
+// CSKY: #define __DBL_MANT_DIG__ 53
+// CSKY: #define __DBL_MAX_10_EXP__ 308
+// CSKY: #define __DBL_MAX_EXP__ 1024
+// CSKY: #define __DBL_MAX__ 1.7976931348623157e+308
+// CSKY: #define __DBL_MIN_10_EXP__ (-307)
+// CSKY: #define __DBL_MIN_EXP__ (-1021)
+// CSKY: #define __DBL_MIN__ 2.2250738585072014e-308
+// CSKY: #define __DECIMAL_DIG__ __LDBL_DECIMAL_DIG__
+// CSKY: #define __ELF__ 1
+// CSKY: #define __FINITE_MATH_ONLY__ 0
+// CSKY: #define __FLT_DECIMAL_DIG__ 9
+// CSKY: #define __FLT_DENORM_MIN__ 1.40129846e-45F
+// CSKY: #define __FLT_DIG__ 6
+// CSKY: #define __FLT_EPSILON__ 1.19209290e-7F
+// CSKY: #define __FLT_HAS_DENORM__ 1
+// CSKY: #define __FLT_HAS_INFINITY__ 1
+// CSKY: #define __FLT_HAS_QUIET_NAN__ 1
+// CSKY: #define __FLT_MANT_DIG__ 24
+// CSKY: #define __FLT_MAX_10_EX

[PATCH] D121445: [Clang][CSKY] Add the CSKY target and compiler driver

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

I have updated the patch. Any more comments?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D121445/new/

https://reviews.llvm.org/D121445

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D121445: [Clang][CSKY] Add the CSKY target and compiler driver

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D121445#3388842 , @rengolin wrote:

> I'm surprised these tests are passing for you. Perhaps you're not building or 
> running them all.
>
> To make sure you're running your tests, you need to build both clang and llvm 
> (`-DLLVM_ENABLE_PROJECTS=clang`) and run ninja/make `check-all`.
>
> You can also run `lit` directly on each test, but I can't remember how to do 
> that now...

I have enabled clang project building and run check-all test. Like ` 
-DLLVM_ENABLE_ASSERTIONS=On -DLLVM_ENABLE_PROJECTS="clang;llvm" 
-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD="CSKY"`. So I am also surprised why those 
cases passed.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D121445/new/

https://reviews.llvm.org/D121445

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D70401: [RISCV] Complete RV32E/ilp32e implementation

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu commandeered this revision.
zixuan-wu added a reviewer: pcwang-thead.
zixuan-wu added a comment.

In D70401#3250049 , @khchen wrote:

> 2. Have you try to run llvm-test-suite with rv32e config on qemu?

It's difficult to run llvm-test-suite in ilp32e abi in Linux. Because there are 
no workable environment such as runtime and kernel for ilp32e in GNU series 
tools.
And we can not run llvm-test-suite in baremental environment(NOT linux but elf 
triple). So I have a question about how to test llvm in elf triple and 
environment? Is there any test case llvm community normally uses and accepts?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70401/new/

https://reviews.llvm.org/D70401

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D70401: [RISCV] Complete RV32E/ilp32e implementation

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

It's difficult to run llvm-test-suite in ilp32e abi in Linux. Because there are 
no workable environment such as runtime and kernel for ilp32e in GNU series 
tools.
And we can not run llvm-test-suite in baremental environment(NOT linux but elf 
triple). So I have a question about how to test llvm in elf triple and 
environment? Is there any test case llvm community normally uses and accepts?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70401/new/

https://reviews.llvm.org/D70401

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D70401: [RISCV] Complete RV32E/ilp32e implementation

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

Sorry for the wrong action of commandeer, @pcwang-thead will still be the 
author.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70401/new/

https://reviews.llvm.org/D70401

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D124977: [NFC][Clang] Modify expect of fail test or XFAIL because CSKY align is different

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu created this revision.
zixuan-wu added reviewers: majnemer, kparzysz, ddunbar.
Herald added a project: All.
zixuan-wu requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

CSKY is always in 4-byte align, no matter it's long long type. For aggregate 
type,  it's 4-byte align if its size is bigger than or equal to 4 bytes.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D124977

Files:
  clang/test/CodeGen/c-strings.c
  clang/test/Sema/builtin-alloca-with-align.c


Index: clang/test/Sema/builtin-alloca-with-align.c
===
--- clang/test/Sema/builtin-alloca-with-align.c
+++ clang/test/Sema/builtin-alloca-with-align.c
@@ -29,5 +29,10 @@
 }
 
 void test8(void) {
+#if defined(__csky__)
   __builtin_alloca_with_align(sizeof(__INT64_TYPE__), 
__alignof__(__INT64_TYPE__)); // expected-warning {{second argument to 
__builtin_alloca_with_align is supposed to be in bits}}
+   
 // expected-error@-1 {{requested alignment must be 8 or greater}}
+#else
+  __builtin_alloca_with_align(sizeof(__INT64_TYPE__), 
__alignof__(__INT64_TYPE__)); // expected-warning {{second argument to 
__builtin_alloca_with_align is supposed to be in bits}}
+#endif
 }
Index: clang/test/CodeGen/c-strings.c
===
--- clang/test/CodeGen/c-strings.c
+++ clang/test/CodeGen/c-strings.c
@@ -20,6 +20,11 @@
 // fails the check for "@f3.x = ... align [ALIGN]", since ALIGN is derived
 // from the alignment of a single i8, which is still 1.
 
+// XFAIL: csky
+// CSKY aligns arrays of size 4+ bytes to a 32-bit boundary, which
+// fails the check for "@f2.x = ... align [ALIGN]", since ALIGN is derived
+// from the alignment of a single i8, which is still 1.
+
 #if defined(__s390x__)
 unsigned char align = 2;
 #else
@@ -69,4 +74,3 @@
 }
 
 char x[3] = "ola";
-


Index: clang/test/Sema/builtin-alloca-with-align.c
===
--- clang/test/Sema/builtin-alloca-with-align.c
+++ clang/test/Sema/builtin-alloca-with-align.c
@@ -29,5 +29,10 @@
 }
 
 void test8(void) {
+#if defined(__csky__)
   __builtin_alloca_with_align(sizeof(__INT64_TYPE__), __alignof__(__INT64_TYPE__)); // expected-warning {{second argument to __builtin_alloca_with_align is supposed to be in bits}}
+// expected-error@-1 {{requested alignment must be 8 or greater}}
+#else
+  __builtin_alloca_with_align(sizeof(__INT64_TYPE__), __alignof__(__INT64_TYPE__)); // expected-warning {{second argument to __builtin_alloca_with_align is supposed to be in bits}}
+#endif
 }
Index: clang/test/CodeGen/c-strings.c
===
--- clang/test/CodeGen/c-strings.c
+++ clang/test/CodeGen/c-strings.c
@@ -20,6 +20,11 @@
 // fails the check for "@f3.x = ... align [ALIGN]", since ALIGN is derived
 // from the alignment of a single i8, which is still 1.
 
+// XFAIL: csky
+// CSKY aligns arrays of size 4+ bytes to a 32-bit boundary, which
+// fails the check for "@f2.x = ... align [ALIGN]", since ALIGN is derived
+// from the alignment of a single i8, which is still 1.
+
 #if defined(__s390x__)
 unsigned char align = 2;
 #else
@@ -69,4 +74,3 @@
 }
 
 char x[3] = "ola";
-
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D124977: [NFC][Clang] Modify expect of fail test or XFAIL because CSKY align is different

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: clang/test/Sema/builtin-alloca-with-align.c:32
 void test8(void) {
+#if defined(__csky__)
   __builtin_alloca_with_align(sizeof(__INT64_TYPE__), 
__alignof__(__INT64_TYPE__)); // expected-warning {{second argument to 
__builtin_alloca_with_align is supposed to be in bits}}

rengolin wrote:
> This test is platform agnostic, perhaps the extra error could be in a new 
> test, exclusively for csky?
Then I prefer to split the file and add UNSUPPORTED for CSKY in the other file 
which only contains test8


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D124977/new/

https://reviews.llvm.org/D124977

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D129824: [RISCV] Set triple based on -march flag which can be deduced in more generic way

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu created this revision.
zixuan-wu added reviewers: simoncook, lenary, asb.
Herald added subscribers: sunshaoce, VincentWu, luke957, StephenFan, vkmr, 
frasercrmck, evandro, luismarques, apazos, sameer.abuasal, s.egerton, Jim, 
benna, psnobl, jocewei, PkmX, the_o, brucehoult, MartinMosbeck, rogfer01, 
edward-jones, zzheng, jrtc27, shiva0217, kito-cheng, niosHD, sabuasal, 
johnrusso, rbar, arichardson.
Herald added a project: All.
zixuan-wu requested review of this revision.
Herald added subscribers: cfe-commits, pcwang-thead, eopXD, MaskRay.
Herald added a project: clang.

Now RISC-V the value provided to -march can determine whether to compile for 
32- or 64-bit RISC-V irrespective of the target provided to the Clang driver. 
Further, -march can be deduced in more generic way without providing -march but 
-mcpu or -mabi.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D129824

Files:
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/riscv-abi.c
  clang/test/Driver/riscv-arch.c


Index: clang/test/Driver/riscv-arch.c
===
--- clang/test/Driver/riscv-arch.c
+++ clang/test/Driver/riscv-arch.c
@@ -392,12 +392,29 @@
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-TARGET %s
 // RUN: %clang --target=riscv64-unknown-elf -march=rv32i -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-TARGET %s
+// RUN: %clang --target=riscv32-unknown-elf -mcpu=sifive-e20 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-TARGET %s
+// RUN: %clang --target=riscv64-unknown-elf -mcpu=sifive-e20 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-TARGET %s
+// RUN: %clang --target=riscv32-unknown-elf -mabi=ilp32 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-TARGET %s
+// RUN: %clang --target=riscv64-unknown-elf -mabi=ilp32 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-TARGET %s
 // RV32-TARGET: "-triple" "riscv32-unknown-unknown-elf"
 
+
 // RUN: %clang --target=riscv32-unknown-elf -march=rv64i -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-TARGET %s
 // RUN: %clang --target=riscv64-unknown-elf -march=rv64i -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-TARGET %s
+// RUN: %clang --target=riscv32-unknown-elf -mcpu=sifive-s21 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-TARGET %s
+// RUN: %clang --target=riscv64-unknown-elf -mcpu=sifive-s21 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-TARGET %s
+// RUN: %clang --target=riscv32-unknown-elf -mabi=lp64 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-TARGET %s
+// RUN: %clang --target=riscv64-unknown-elf -mabi=lp64 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-TARGET %s
 // RV64-TARGET: "-triple" "riscv64-unknown-unknown-elf"
 
 // RUN: %clang --target=riscv32-unknown-elf -march=rv32ifzfh01p0 -### %s \
Index: clang/test/Driver/riscv-abi.c
===
--- clang/test/Driver/riscv-abi.c
+++ clang/test/Driver/riscv-abi.c
@@ -40,11 +40,6 @@
 
 // CHECK-ILP32D: "-target-abi" "ilp32d"
 
-// RUN: not %clang --target=riscv32-unknown-elf %s -o %t.o -mabi=lp64 2>&1 \
-// RUN:   | FileCheck -check-prefix=CHECK-RV32-LP64 %s
-
-// CHECK-RV32-LP64: error: unknown target ABI 'lp64'
-
 // RUN: %clang --target=riscv64-unknown-elf %s -### 2>&1 \
 // RUN:   | FileCheck -check-prefix=CHECK-LP64 %s
 // RUN: %clang --target=riscv64-unknown-elf %s -### -mabi=lp64 2>&1 \
@@ -77,8 +72,3 @@
 // RUN:   | FileCheck -check-prefix=CHECK-LP64D  %s
 
 // CHECK-LP64D: "-target-abi" "lp64d"
-
-// RUN: not %clang --target=riscv64-unknown-elf %s -o %t.o -mabi=ilp32 2>&1 \
-// RUN:   | FileCheck -check-prefix=CHECK-RV64-ILP32 %s
-
-// CHECK-RV64-ILP32: error: unknown target ABI 'ilp32'
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -7,6 +7,8 @@
 
//===--===//
 
 #include "clang/Driver/Driver.h"
+#include "ToolChains/Arch/RISCV.h"
+#include "ToolChains/AIX.h"
 #include "ToolChains/AIX.h"
 #include "ToolChains/AMDGPU.h"
 #include "ToolChains/AMDGPUOpenMP.h"
@@ -650,13 +652,16 @@
   }
 
   // If target is RISC-V adjust the target triple according to
-  // provided architecture name
-  A = Args.getLastArg(options::OPT_march_EQ);
-  if (A && Target.isRISCV()) {
-StringRef ArchName = A->getValue();
-if (ArchName.startswith_insensitive("rv32"))
+  // provided architecture relative info such as -march/-mcpu/-mabi.
+  if (Target.isRISCV()) {
+StringRef ArchName = tools::riscv::getRISCVArch(Args, Target);
+llvm::Triple::ArchType RVArch = Target.getArch();
+
+if (RVArch == llvm::Triple::riscv64 &&
+ArchName.startswith_insensitive("rv32"))
 

[PATCH] D54214: [RISCV] Set triple based on -march flag

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.
Herald added subscribers: sunshaoce, pcwang-thead, eopXD, VincentWu, luke957, 
StephenFan, vkmr, frasercrmck, evandro, luismarques, MaskRay, arichardson.
Herald added a project: All.

In D54214#1737255 , @simoncook wrote:

> Rebase.
>
> @lenary Following the discussion regarding D69383 
> , I think it's best for now to keep the 
> logic just keeping `-march` directly, rather than using `getRISCVArch`. I 
> think in the case of `-target risc32-. -mabi=lp64` I think it would 
> confuse users if the tools suddenly changed to doing an rv64 compile. If we 
> disable that, all that function would provide me is the same StringRef I'm 
> already evaluating. I think adding any extra flag to indicate whether a 
> rv32<->rv64 switch is acceptable would just make the code unnecessarily more 
> messy. I think in the future if `getRISCVArch` evaluates more flags, then it 
> might make sense to reconsider this.

I think the case of `-target risc32-. -mabi=lp64` is acceptable since the 
-target is less usable than -march/-mabi/-mcpu and is almost invisible to users.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D54214/new/

https://reviews.llvm.org/D54214

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D129824: [RISCV] Set triple based on -march flag which can be deduced in more generic way

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D129824#3653895 , @jrtc27 wrote:

> Does GCC allow this or not? Because this strikes me as a bad idea at first 
> sight…

GCC can deduce from -mcpu but not -mabi.

> riscv64-unknown-linux-gnu-gcc a.c -mabi=ilp32
> cc1: error: ABI requires '-march=rv32'

But I think it can be negotiated.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129824/new/

https://reviews.llvm.org/D129824

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D129824: [RISCV] Set triple based on -march flag which can be deduced in more generic way

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: clang/lib/Driver/Driver.cpp:660
+
+if (RVArch == llvm::Triple::riscv64 &&
+ArchName.startswith_insensitive("rv32"))

eopXD wrote:
> Do we need to throw error (or warning) when these two (`RVArch` and 
> `ArchName`) don't match?
It just overrides it as before to not report error when for example default 
triple is rv64 with user passing -march=rv32xxx


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129824/new/

https://reviews.llvm.org/D129824

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D129824: [RISCV] Set triple based on -march flag which can be deduced in more generic way

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu updated this revision to Diff 445690.
zixuan-wu added a comment.

Remove unnecessary include header.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129824/new/

https://reviews.llvm.org/D129824

Files:
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/riscv-abi.c
  clang/test/Driver/riscv-arch.c


Index: clang/test/Driver/riscv-arch.c
===
--- clang/test/Driver/riscv-arch.c
+++ clang/test/Driver/riscv-arch.c
@@ -392,12 +392,29 @@
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-TARGET %s
 // RUN: %clang --target=riscv64-unknown-elf -march=rv32i -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-TARGET %s
+// RUN: %clang --target=riscv32-unknown-elf -mcpu=sifive-e20 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-TARGET %s
+// RUN: %clang --target=riscv64-unknown-elf -mcpu=sifive-e20 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-TARGET %s
+// RUN: %clang --target=riscv32-unknown-elf -mabi=ilp32 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-TARGET %s
+// RUN: %clang --target=riscv64-unknown-elf -mabi=ilp32 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-TARGET %s
 // RV32-TARGET: "-triple" "riscv32-unknown-unknown-elf"
 
+
 // RUN: %clang --target=riscv32-unknown-elf -march=rv64i -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-TARGET %s
 // RUN: %clang --target=riscv64-unknown-elf -march=rv64i -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-TARGET %s
+// RUN: %clang --target=riscv32-unknown-elf -mcpu=sifive-s21 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-TARGET %s
+// RUN: %clang --target=riscv64-unknown-elf -mcpu=sifive-s21 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-TARGET %s
+// RUN: %clang --target=riscv32-unknown-elf -mabi=lp64 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-TARGET %s
+// RUN: %clang --target=riscv64-unknown-elf -mabi=lp64 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-TARGET %s
 // RV64-TARGET: "-triple" "riscv64-unknown-unknown-elf"
 
 // RUN: %clang --target=riscv32-unknown-elf -march=rv32ifzfh01p0 -### %s \
Index: clang/test/Driver/riscv-abi.c
===
--- clang/test/Driver/riscv-abi.c
+++ clang/test/Driver/riscv-abi.c
@@ -40,11 +40,6 @@
 
 // CHECK-ILP32D: "-target-abi" "ilp32d"
 
-// RUN: not %clang --target=riscv32-unknown-elf %s -o %t.o -mabi=lp64 2>&1 \
-// RUN:   | FileCheck -check-prefix=CHECK-RV32-LP64 %s
-
-// CHECK-RV32-LP64: error: unknown target ABI 'lp64'
-
 // RUN: %clang --target=riscv64-unknown-elf %s -### 2>&1 \
 // RUN:   | FileCheck -check-prefix=CHECK-LP64 %s
 // RUN: %clang --target=riscv64-unknown-elf %s -### -mabi=lp64 2>&1 \
@@ -77,8 +72,3 @@
 // RUN:   | FileCheck -check-prefix=CHECK-LP64D  %s
 
 // CHECK-LP64D: "-target-abi" "lp64d"
-
-// RUN: not %clang --target=riscv64-unknown-elf %s -o %t.o -mabi=ilp32 2>&1 \
-// RUN:   | FileCheck -check-prefix=CHECK-RV64-ILP32 %s
-
-// CHECK-RV64-ILP32: error: unknown target ABI 'ilp32'
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -7,6 +7,7 @@
 
//===--===//
 
 #include "clang/Driver/Driver.h"
+#include "ToolChains/Arch/RISCV.h"
 #include "ToolChains/AIX.h"
 #include "ToolChains/AMDGPU.h"
 #include "ToolChains/AMDGPUOpenMP.h"
@@ -650,13 +651,16 @@
   }
 
   // If target is RISC-V adjust the target triple according to
-  // provided architecture name
-  A = Args.getLastArg(options::OPT_march_EQ);
-  if (A && Target.isRISCV()) {
-StringRef ArchName = A->getValue();
-if (ArchName.startswith_insensitive("rv32"))
+  // provided architecture relative info such as -march/-mcpu/-mabi.
+  if (Target.isRISCV()) {
+StringRef ArchName = tools::riscv::getRISCVArch(Args, Target);
+llvm::Triple::ArchType RVArch = Target.getArch();
+
+if (RVArch == llvm::Triple::riscv64 &&
+ArchName.startswith_insensitive("rv32"))
   Target.setArch(llvm::Triple::riscv32);
-else if (ArchName.startswith_insensitive("rv64"))
+else if (RVArch == llvm::Triple::riscv32 &&
+ ArchName.startswith_insensitive("rv64"))
   Target.setArch(llvm::Triple::riscv64);
   }
 


Index: clang/test/Driver/riscv-arch.c
===
--- clang/test/Driver/riscv-arch.c
+++ clang/test/Driver/riscv-arch.c
@@ -392,12 +392,29 @@
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-TARGET %s
 // RUN: %clang --target=riscv64-unknown-elf -march=rv32i -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-TARGET %s
+// RUN: %clang --target=riscv32-unknown-elf -mcpu=sifive-e20 -### %s

[PATCH] D129824: [RISCV] Set triple based on -march flag which can be deduced in more generic way

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D129824#3670586 , @reames wrote:

> This was very briefly discussed at today's sync up call.  We were running 
> short on time, so we didn't get a chance to talk through it, but there did 
> seem to be a consensus that discussion on the interface implications was 
> needed.  This should hopefully be on the agenda when we talk again in two 
> weeks.

Okay. Anybody else please more comments here before next sync-up call if you 
have.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129824/new/

https://reviews.llvm.org/D129824

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D124977: [NFC][Clang] Modify expect of fail test or XFAIL because CSKY align is different

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

Could anybody else have a review or nominate a reviewer?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D124977/new/

https://reviews.llvm.org/D124977

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D124977: [NFC][Clang] Modify expect of fail test or XFAIL because CSKY align is different

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: clang/test/Sema/builtin-alloca-with-align.c:32
 void test8(void) {
+#if defined(__csky__)
   __builtin_alloca_with_align(sizeof(__INT64_TYPE__), 
__alignof__(__INT64_TYPE__)); // expected-warning {{second argument to 
__builtin_alloca_with_align is supposed to be in bits}}

aaron.ballman wrote:
> rengolin wrote:
> > zixuan-wu wrote:
> > > rengolin wrote:
> > > > This test is platform agnostic, perhaps the extra error could be in a 
> > > > new test, exclusively for csky?
> > > Then I prefer to split the file and add UNSUPPORTED for CSKY in the other 
> > > file which only contains test8
> > But then you wouldn't be testing the extra error you want... hmm.
> > 
> > Maybe it would be fine the way you did it originally.
> > 
> > Would be nice to get a clang person to give their opinion.
>   // Comment which explains why this is special.
> I think I would test this slightly differently:
> ```
> void test8(void) {
>   __builtin_alloca_with_align(sizeof(__INT64_TYPE__), 
> __alignof__(__INT64_TYPE__)); // expected-warning {{second argument to 
> __builtin_alloca_with_align is supposed to be in bits}}
> #ifdef __csky__
>   // expected-error@-2 {{requested alignment must be 8 or greater}}
>   // Comment which explains why this is special.
> #endif // __csky__
> }
> ```
Reusing the first warning is good.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D124977/new/

https://reviews.llvm.org/D124977

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D124977: [NFC][Clang] Modify expect of fail test or XFAIL because CSKY align is different

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu updated this revision to Diff 428585.
zixuan-wu added a comment.

Address comments.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D124977/new/

https://reviews.llvm.org/D124977

Files:
  clang/test/CodeGen/c-strings.c
  clang/test/Sema/builtin-alloca-with-align.c


Index: clang/test/Sema/builtin-alloca-with-align.c
===
--- clang/test/Sema/builtin-alloca-with-align.c
+++ clang/test/Sema/builtin-alloca-with-align.c
@@ -30,4 +30,8 @@
 
 void test8(void) {
   __builtin_alloca_with_align(sizeof(__INT64_TYPE__), 
__alignof__(__INT64_TYPE__)); // expected-warning {{second argument to 
__builtin_alloca_with_align is supposed to be in bits}}
+#if defined(__csky__)
+  // expected-error@-1 {{requested alignment must be 8 or greater}}
+  // Because the alignment of long long is 4 in CSKY target
+#endif
 }
Index: clang/test/CodeGen/c-strings.c
===
--- clang/test/CodeGen/c-strings.c
+++ clang/test/CodeGen/c-strings.c
@@ -20,6 +20,11 @@
 // fails the check for "@f3.x = ... align [ALIGN]", since ALIGN is derived
 // from the alignment of a single i8, which is still 1.
 
+// XFAIL: csky
+// CSKY aligns arrays of size 4+ bytes to a 32-bit boundary, which
+// fails the check for "@f2.x = ... align [ALIGN]", since ALIGN is derived
+// from the alignment of a single i8, which is still 1.
+
 #if defined(__s390x__)
 unsigned char align = 2;
 #else
@@ -69,4 +74,3 @@
 }
 
 char x[3] = "ola";
-


Index: clang/test/Sema/builtin-alloca-with-align.c
===
--- clang/test/Sema/builtin-alloca-with-align.c
+++ clang/test/Sema/builtin-alloca-with-align.c
@@ -30,4 +30,8 @@
 
 void test8(void) {
   __builtin_alloca_with_align(sizeof(__INT64_TYPE__), __alignof__(__INT64_TYPE__)); // expected-warning {{second argument to __builtin_alloca_with_align is supposed to be in bits}}
+#if defined(__csky__)
+  // expected-error@-1 {{requested alignment must be 8 or greater}}
+  // Because the alignment of long long is 4 in CSKY target
+#endif
 }
Index: clang/test/CodeGen/c-strings.c
===
--- clang/test/CodeGen/c-strings.c
+++ clang/test/CodeGen/c-strings.c
@@ -20,6 +20,11 @@
 // fails the check for "@f3.x = ... align [ALIGN]", since ALIGN is derived
 // from the alignment of a single i8, which is still 1.
 
+// XFAIL: csky
+// CSKY aligns arrays of size 4+ bytes to a 32-bit boundary, which
+// fails the check for "@f2.x = ... align [ALIGN]", since ALIGN is derived
+// from the alignment of a single i8, which is still 1.
+
 #if defined(__s390x__)
 unsigned char align = 2;
 #else
@@ -69,4 +74,3 @@
 }
 
 char x[3] = "ola";
-
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D124977: [NFC][Clang] Modify expect of fail test or XFAIL because CSKY align is different

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

Gentle pin..


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D124977/new/

https://reviews.llvm.org/D124977

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D124977: [NFC][Clang] Modify expect of fail test or XFAIL because CSKY align is different

[Zixuan Wu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGdca37af061fb: [NFC][Clang] Modify expect of fail test or 
XFAIL because CSKY align is different (authored by zixuan-wu).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D124977/new/

https://reviews.llvm.org/D124977

Files:
  clang/test/CodeGen/c-strings.c
  clang/test/Sema/builtin-alloca-with-align.c


Index: clang/test/Sema/builtin-alloca-with-align.c
===
--- clang/test/Sema/builtin-alloca-with-align.c
+++ clang/test/Sema/builtin-alloca-with-align.c
@@ -30,4 +30,8 @@
 
 void test8(void) {
   __builtin_alloca_with_align(sizeof(__INT64_TYPE__), 
__alignof__(__INT64_TYPE__)); // expected-warning {{second argument to 
__builtin_alloca_with_align is supposed to be in bits}}
+#if defined(__csky__)
+  // expected-error@-1 {{requested alignment must be 8 or greater}}
+  // Because the alignment of long long is 4 in CSKY target
+#endif
 }
Index: clang/test/CodeGen/c-strings.c
===
--- clang/test/CodeGen/c-strings.c
+++ clang/test/CodeGen/c-strings.c
@@ -20,6 +20,11 @@
 // fails the check for "@f3.x = ... align [ALIGN]", since ALIGN is derived
 // from the alignment of a single i8, which is still 1.
 
+// XFAIL: csky
+// CSKY aligns arrays of size 4+ bytes to a 32-bit boundary, which
+// fails the check for "@f2.x = ... align [ALIGN]", since ALIGN is derived
+// from the alignment of a single i8, which is still 1.
+
 #if defined(__s390x__)
 unsigned char align = 2;
 #else
@@ -69,4 +74,3 @@
 }
 
 char x[3] = "ola";
-


Index: clang/test/Sema/builtin-alloca-with-align.c
===
--- clang/test/Sema/builtin-alloca-with-align.c
+++ clang/test/Sema/builtin-alloca-with-align.c
@@ -30,4 +30,8 @@
 
 void test8(void) {
   __builtin_alloca_with_align(sizeof(__INT64_TYPE__), __alignof__(__INT64_TYPE__)); // expected-warning {{second argument to __builtin_alloca_with_align is supposed to be in bits}}
+#if defined(__csky__)
+  // expected-error@-1 {{requested alignment must be 8 or greater}}
+  // Because the alignment of long long is 4 in CSKY target
+#endif
 }
Index: clang/test/CodeGen/c-strings.c
===
--- clang/test/CodeGen/c-strings.c
+++ clang/test/CodeGen/c-strings.c
@@ -20,6 +20,11 @@
 // fails the check for "@f3.x = ... align [ALIGN]", since ALIGN is derived
 // from the alignment of a single i8, which is still 1.
 
+// XFAIL: csky
+// CSKY aligns arrays of size 4+ bytes to a 32-bit boundary, which
+// fails the check for "@f2.x = ... align [ALIGN]", since ALIGN is derived
+// from the alignment of a single i8, which is still 1.
+
 #if defined(__s390x__)
 unsigned char align = 2;
 #else
@@ -69,4 +74,3 @@
 }
 
 char x[3] = "ola";
-
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D70401: [RISCV] CodeGen of RVE and ilp32e/lp64e ABIs

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu accepted this revision.
zixuan-wu added a comment.
This revision is now accepted and ready to land.

LGTM if nobody objects.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70401/new/

https://reviews.llvm.org/D70401

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D8467: C++14: Disable sized deallocation by default due to ABI breakage

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.
Herald added a subscriber: dang.

Hi, I am wondering could -fsized-deallocation this be enabled by default 
nowadays in 2021?


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D8467/new/

https://reviews.llvm.org/D8467

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D105168: [RISCV] Unify the arch string parsing logic to RISCVISAInfo.

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.
Herald added subscribers: VincentWu, luke957.

Hi, @kito-cheng as your this patch unify the extension handing in one same 
place by new infra, are you going to support the multiple extension version in 
next step?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105168/new/

https://reviews.llvm.org/D105168

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D8467: C++14: Disable sized deallocation by default due to ABI breakage

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D8467#3125313 , @tstellar wrote:

> In D8467#3095610 , @zixuan-wu wrote:
>
>> Hi, I am wondering could -fsized-deallocation this be enabled by default 
>> nowadays in 2021?
>
> Were you planning to work on this?

It's been working on at https://reviews.llvm.org/D112921


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D8467/new/

https://reviews.llvm.org/D8467

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D112921: [clang] Enable sized deallocation by default in C++14 onwards

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

Is this going to be reviewed again or committed?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D112921/new/

https://reviews.llvm.org/D112921

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D70401: [WIP][RISCV] Implement ilp32e ABI

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.
Herald added subscribers: VincentWu, luke957, achieveartificialintelligence.

Hi, all. Why is it not continued?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70401/new/

https://reviews.llvm.org/D70401

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D136239: [testcase] [OpenMP] Fix the testcase error of check-all when DCLANG_DEFAULT_OPENMP_RUNTIME is not libomp

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu created this revision.
zixuan-wu added reviewers: jdoerfert, MaskRay.
Herald added subscribers: StephenFan, arphaman, guansong, yaxunl.
Herald added a project: All.
zixuan-wu requested review of this revision.
Herald added subscribers: cfe-commits, sstefan1.
Herald added a project: clang.

When DCLANG_DEFAULT_OPENMP_RUNTIME is set to libgomp, there is some check-all 
error. The expected CHECK result only displays when fopenmp=libomp is specified 
explicitly.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D136239

Files:
  clang/test/Driver/fopenmp.c
  clang/test/Index/openmp-tile.c


Index: clang/test/Index/openmp-tile.c
===
--- clang/test/Index/openmp-tile.c
+++ clang/test/Index/openmp-tile.c
@@ -1,4 +1,4 @@
-// RUN: c-index-test -test-load-source local %s -fopenmp -fopenmp-version=51 | 
FileCheck %s
+// RUN: c-index-test -test-load-source local %s -fopenmp=libomp 
-fopenmp-version=51 | FileCheck %s
 
 void test() {
 #pragma omp tile sizes(5)
Index: clang/test/Driver/fopenmp.c
===
--- clang/test/Driver/fopenmp.c
+++ clang/test/Driver/fopenmp.c
@@ -140,7 +140,7 @@
 // CHECK-LD-STATIC-IOMP5-NO-BDYNAMIC: "-{{B?}}static" {{.*}} "-liomp5"
 // CHECK-LD-STATIC-IOMP5-NO-BDYNAMIC-NOT: "-Bdynamic"
 //
-// RUN: %clang -target x86_64-linux-gnu -fopenmp -fopenmp-enable-irbuilder -c 
%s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CC1-OPENMPIRBUILDER
+// RUN: %clang -target x86_64-linux-gnu -fopenmp=libomp 
-fopenmp-enable-irbuilder -c %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-CC1-OPENMPIRBUILDER
 //
 // CHECK-CC1-OPENMPIRBUILDER: "-cc1"
 // CHECK-CC1-OPENMPIRBUILDER-SAME: "-fopenmp"


Index: clang/test/Index/openmp-tile.c
===
--- clang/test/Index/openmp-tile.c
+++ clang/test/Index/openmp-tile.c
@@ -1,4 +1,4 @@
-// RUN: c-index-test -test-load-source local %s -fopenmp -fopenmp-version=51 | FileCheck %s
+// RUN: c-index-test -test-load-source local %s -fopenmp=libomp -fopenmp-version=51 | FileCheck %s
 
 void test() {
 #pragma omp tile sizes(5)
Index: clang/test/Driver/fopenmp.c
===
--- clang/test/Driver/fopenmp.c
+++ clang/test/Driver/fopenmp.c
@@ -140,7 +140,7 @@
 // CHECK-LD-STATIC-IOMP5-NO-BDYNAMIC: "-{{B?}}static" {{.*}} "-liomp5"
 // CHECK-LD-STATIC-IOMP5-NO-BDYNAMIC-NOT: "-Bdynamic"
 //
-// RUN: %clang -target x86_64-linux-gnu -fopenmp -fopenmp-enable-irbuilder -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CC1-OPENMPIRBUILDER
+// RUN: %clang -target x86_64-linux-gnu -fopenmp=libomp -fopenmp-enable-irbuilder -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CC1-OPENMPIRBUILDER
 //
 // CHECK-CC1-OPENMPIRBUILDER: "-cc1"
 // CHECK-CC1-OPENMPIRBUILDER-SAME: "-fopenmp"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D136239: [testcase] [OpenMP] Fix the testcase error of check-all when DCLANG_DEFAULT_OPENMP_RUNTIME is not libomp

[Zixuan Wu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG55c2137939d8: [testcase][OpenMP] Fix the testcase error of 
check-all when… (authored by zixuan-wu).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136239/new/

https://reviews.llvm.org/D136239

Files:
  clang/test/Driver/fopenmp.c
  clang/test/Index/openmp-tile.c


Index: clang/test/Index/openmp-tile.c
===
--- clang/test/Index/openmp-tile.c
+++ clang/test/Index/openmp-tile.c
@@ -1,4 +1,4 @@
-// RUN: c-index-test -test-load-source local %s -fopenmp -fopenmp-version=51 | 
FileCheck %s
+// RUN: c-index-test -test-load-source local %s -fopenmp=libomp 
-fopenmp-version=51 | FileCheck %s
 
 void test() {
 #pragma omp tile sizes(5)
Index: clang/test/Driver/fopenmp.c
===
--- clang/test/Driver/fopenmp.c
+++ clang/test/Driver/fopenmp.c
@@ -140,7 +140,7 @@
 // CHECK-LD-STATIC-IOMP5-NO-BDYNAMIC: "-{{B?}}static" {{.*}} "-liomp5"
 // CHECK-LD-STATIC-IOMP5-NO-BDYNAMIC-NOT: "-Bdynamic"
 //
-// RUN: %clang -target x86_64-linux-gnu -fopenmp -fopenmp-enable-irbuilder -c 
%s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CC1-OPENMPIRBUILDER
+// RUN: %clang -target x86_64-linux-gnu -fopenmp=libomp 
-fopenmp-enable-irbuilder -c %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-CC1-OPENMPIRBUILDER
 //
 // CHECK-CC1-OPENMPIRBUILDER: "-cc1"
 // CHECK-CC1-OPENMPIRBUILDER-SAME: "-fopenmp"


Index: clang/test/Index/openmp-tile.c
===
--- clang/test/Index/openmp-tile.c
+++ clang/test/Index/openmp-tile.c
@@ -1,4 +1,4 @@
-// RUN: c-index-test -test-load-source local %s -fopenmp -fopenmp-version=51 | FileCheck %s
+// RUN: c-index-test -test-load-source local %s -fopenmp=libomp -fopenmp-version=51 | FileCheck %s
 
 void test() {
 #pragma omp tile sizes(5)
Index: clang/test/Driver/fopenmp.c
===
--- clang/test/Driver/fopenmp.c
+++ clang/test/Driver/fopenmp.c
@@ -140,7 +140,7 @@
 // CHECK-LD-STATIC-IOMP5-NO-BDYNAMIC: "-{{B?}}static" {{.*}} "-liomp5"
 // CHECK-LD-STATIC-IOMP5-NO-BDYNAMIC-NOT: "-Bdynamic"
 //
-// RUN: %clang -target x86_64-linux-gnu -fopenmp -fopenmp-enable-irbuilder -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CC1-OPENMPIRBUILDER
+// RUN: %clang -target x86_64-linux-gnu -fopenmp=libomp -fopenmp-enable-irbuilder -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CC1-OPENMPIRBUILDER
 //
 // CHECK-CC1-OPENMPIRBUILDER: "-cc1"
 // CHECK-CC1-OPENMPIRBUILDER-SAME: "-fopenmp"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D129824: [RISCV] Set triple based on -march flag which can be deduced in more generic way

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu marked an inline comment as not done.
zixuan-wu added a comment.

ping...


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129824/new/

https://reviews.llvm.org/D129824

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D129824: [RISCV] Set triple based on -march flag which can be deduced in more generic way

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

AFAIK, --target is clang-specific and transparent for compiler user in RV side. 
-m is also undefined or less used by RV user. It just uses -march to specify 32 
or 64 mode and extensions.
Is the convention specified in RV Spec?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129824/new/

https://reviews.llvm.org/D129824

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D121445: [Clang][CSKY] Add the CSKY target and compiler driver

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D121445#3824657 , @MaskRay wrote:

> mips computed sysroot from GCCInstallation very early in 2013 
> rG08450bd55ccdc4aee4f5f73cde97e25b3c4ce5b9 
>  and 
> Android followed up in 2018 (D45291 ), but I 
> am not sure this is the correct direction.
> They are to support very special distributions. Hard coding the file 
> hierarchy for every Linux distribution just does not scale.
> I raised my concern on https://reviews.llvm.org/D134454#3824630 as well.
>
> With https://reviews.llvm.org/D134337 (default configuration file) we should 
> move the logic to use a default configuration file instead.

It's fine for me to use config file. I only have 2 points.

1. I agree sysroot should be separated from GCC because sysroot is not 
dependent to GCC and there is even not gcc when we use llvm runtime. This rule 
should also apply to multilib logic. Sysroot can detect multilib path 
individually.
2. From user view,  it's not easy to add sysroot or config file path manually, 
so it needs good way to enable this functionality.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D121445/new/

https://reviews.llvm.org/D121445

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134454: [Driver][Distro] Fix ArchLinux sysroot detection

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

It's fine for CSKY to use config file. I only have 2 points.

1. I agree sysroot should be separated from GCC because sysroot is not 
dependent to GCC and there is even not gcc when we use llvm runtime. This rule 
should also apply to multilib logic. Sysroot can detect multilib path 
individually.
2. From user view, it's not easy to add sysroot or config file path manually, 
so it needs good way to enable this functionality.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134454/new/

https://reviews.llvm.org/D134454

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D70401: [RISCV] Complete RV32E/ilp32e implementation

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: llvm/lib/Target/RISCV/RISCVRegisterInfo.cpp:106
+for (size_t Reg = RISCV::X16; Reg <= RISCV::X31; Reg++)
+  markSuperRegs(Reserved, Reg);
+

I am wondering whether we need construct another new RegisterClass for RV32E 
instead of GPR, for example eGPR, so that the num and other info such as 
weight, etc of RegisterClass can adjust. Then the reserved logic is not 
necessary.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70401/new/

https://reviews.llvm.org/D70401

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D116735: [RISCV] Adjust RISCV data layout by using n32:64 in layout string

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D116735#3429850 , @craig.topper 
wrote:

> I'm seeing a regression on 401.bzip2 and possibly 471.astar. And I'm not 
> seeing large improvements on 471.omnetpp or 483.xalancbmk.

LGTM. But do you still get regression on spec? Or any improvements?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D116735/new/

https://reviews.llvm.org/D116735

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D70401: [RISCV] Complete RV32E/ilp32e implementation

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: llvm/lib/Target/RISCV/RISCVFrameLowering.cpp:411
 // implemented such that the stack will always be 16 byte aligned.
 unsigned LibCallFrameSize = alignTo((STI.getXLen() / 8) * LibCallRegs, 16);
 RVFI->setLibCallStackSize(LibCallFrameSize);

I think this 16 should be adjusted as above logic for rv32e


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70401/new/

https://reviews.llvm.org/D70401

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D137838: [Support] Move TargetParsers to new component

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: llvm/include/llvm/Support/RISCVISAInfo.h:10
+/// \file
+/// This header is deprecated in favour of `llvm/Support/RISCVISAInfo.h`.
+///

I think there is a typo that should be 'in favour of 
`llvm/TargetParser/RISCVISAInfo.h` '


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137838/new/

https://reviews.llvm.org/D137838

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D141899: [IR][X86] Remove X86AMX type in LLVM IR instead of target extension

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D141899#4058173 , @LuoYuanke wrote:

> @zixuan-wu, changing x86_amx would break our internal code. May I know the 
> motivation to change the type?

The background is at https://reviews.llvm.org/D135202. No more motivation, just 
to purify LLVM IR and demonstrate target extension. I think putting 
target-specific type into LLVM IR was thoughtless at that moment. Considering 
there was no better solution at that time such as target extension, it's a 
workable workaround. But it should not keep going anymore if there is better 
way.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D141899/new/

https://reviews.llvm.org/D141899

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D141899: [IR][X86] Remove X86AMX type in LLVM IR instead of target extension

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

With considering 
https://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility I think 
we need make consensus to choose one option from following 2 options.

1. Remove X86amx type in IR totally. (what I am doing now)
2. Without removing X86amx type in IR, just upgrade the x86amx type to target 
extension and also upgrade bitcast llvm instruction to intrinsic(required). It 
also includes changing the testcase to target extension type.

BTW, need we make consensus about whether to do this purify patch anymore?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D141899/new/

https://reviews.llvm.org/D141899

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D126451: [Clang][CSKY] Add support about CSKYABIInfo

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu created this revision.
zixuan-wu added reviewers: rengolin, DavidSpickett.
Herald added a project: All.
zixuan-wu requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

According to the CSKY ABIv2 document 
,
 construct the ABIInfo to handle argument passing and return of clang data 
type. It also includes how to emit and expand VAArg intrinsic.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D126451

Files:
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGen/CSKY/csky-abi.c
  clang/test/CodeGen/CSKY/csky-hard-abi.c

Index: clang/test/CodeGen/CSKY/csky-hard-abi.c
===
--- /dev/null
+++ clang/test/CodeGen/CSKY/csky-hard-abi.c
@@ -0,0 +1,394 @@
+// RUN: %clang_cc1 -no-opaque-pointers -triple csky -target-feature +fpuv2_sf -target-feature +fpuv2_df -target-feature +hard-float-abi -target-feature +hard-float -emit-llvm %s -o - | FileCheck %s
+
+#include 
+
+// Verify that the tracking of used GPRs and FPRs works correctly by checking
+// that small integers are sign/zero extended when passed in registers.
+
+// Doubles are passed in FPRs, so argument 'i' will be passed zero-extended
+// because it will be passed in a GPR.
+
+// CHECK: define{{.*}} void @f_fpr_tracking(double noundef %a, double noundef %b, double noundef %c, double noundef %d, i8 noundef zeroext %i)
+void f_fpr_tracking(double a, double b, double c, double d, uint8_t i) {}
+
+// A struct containing just one floating-point real is passed as though it
+// were a standalone floating-point real.
+struct double_s {
+  double f;
+};
+
+// CHECK: define{{.*}} void @f_double_s_arg(double %a.coerce)
+void f_double_s_arg(struct double_s a) {}
+
+// CHECK: define{{.*}} double @f_ret_double_s()
+struct double_s f_ret_double_s(void) {
+  return (struct double_s){1.0};
+}
+
+// A struct containing a double and any number of zero-width bitfields is
+// passed as though it were a standalone floating-point real.
+
+struct zbf_double_s {
+  int : 0;
+  double f;
+};
+struct zbf_double_zbf_s {
+  int : 0;
+  double f;
+  int : 0;
+};
+
+// CHECK: define{{.*}} void @f_zbf_double_s_arg(double %a.coerce)
+void f_zbf_double_s_arg(struct zbf_double_s a) {}
+
+// CHECK: define{{.*}} double @f_ret_zbf_double_s()
+struct zbf_double_s f_ret_zbf_double_s(void) {
+  return (struct zbf_double_s){1.0};
+}
+
+// CHECK: define{{.*}} void @f_zbf_double_zbf_s_arg(double %a.coerce)
+void f_zbf_double_zbf_s_arg(struct zbf_double_zbf_s a) {}
+
+// CHECK: define{{.*}} double @f_ret_zbf_double_zbf_s()
+struct zbf_double_zbf_s f_ret_zbf_double_zbf_s(void) {
+  return (struct zbf_double_zbf_s){1.0};
+}
+
+// For argument type, the first 4*XLen parts of aggregate will be passed
+// in registers, and the rest will be passed in stack.
+// So we can coerce to integers directly and let backend handle it correctly.
+// For return type, aggregate which <= 2*XLen will be returned in registers.
+// Otherwise, aggregate will be returned indirectly.
+
+struct double_double_s {
+  double f;
+  double g;
+};
+struct double_float_s {
+  double f;
+  float g;
+};
+
+// CHECK: define{{.*}} void @f_double_double_s_arg([4 x i32] %a.coerce)
+void f_double_double_s_arg(struct double_double_s a) {}
+
+// CHECK: define{{.*}} void @f_ret_double_double_s(%struct.double_double_s* noalias sret(%struct.double_double_s) align 4 %agg.result)
+struct double_double_s f_ret_double_double_s(void) {
+  return (struct double_double_s){1.0, 2.0};
+}
+
+// CHECK: define{{.*}} void @f_double_float_s_arg([3 x i32] %a.coerce)
+void f_double_float_s_arg(struct double_float_s a) {}
+
+// CHECK: define{{.*}} void @f_ret_double_float_s(%struct.double_float_s* noalias sret(%struct.double_float_s) align 4 %agg.result)
+struct double_float_s f_ret_double_float_s(void) {
+  return (struct double_float_s){1.0, 2.0};
+}
+
+// CHECK: define{{.*}} void @f_double_double_s_arg_insufficient_fprs(float noundef %a, double noundef %b, double noundef %c, double noundef %d, double noundef %e, double noundef %f, double noundef %g, double noundef %i, [4 x i32] %h.coerce)
+void f_double_double_s_arg_insufficient_fprs(float a, double b, double c, double d,
+ double e, double f, double g, double i, struct double_double_s h) {}
+
+struct double_int8_s {
+  double f;
+  int8_t i;
+};
+struct double_uint8_s {
+  double f;
+  uint8_t i;
+};
+struct double_int32_s {
+  double f;
+  int32_t i;
+};
+struct double_int64_s {
+  double f;
+  int64_t i;
+};
+struct double_int64bf_s {
+  double f;
+  int64_t i : 32;
+};
+struct double_int8_zbf_s {
+  double f;
+  int8_t i;
+  int : 0;
+};
+
+// CHECK: define{{.*}}  @f_double_int8_s_arg([3 x i32] %a.coerce)
+void f_double_int8_s_arg(struct double_int8_s a) {}
+
+// CHECK: define{{.*}} void @f_ret_double_int8_s(%struc

[PATCH] D126451: [Clang][CSKY] Add support about CSKYABIInfo

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu updated this revision to Diff 432228.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126451/new/

https://reviews.llvm.org/D126451

Files:
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGen/CSKY/csky-abi.c
  clang/test/CodeGen/CSKY/csky-hard-abi.c

Index: clang/test/CodeGen/CSKY/csky-hard-abi.c
===
--- /dev/null
+++ clang/test/CodeGen/CSKY/csky-hard-abi.c
@@ -0,0 +1,394 @@
+// RUN: %clang_cc1 -no-opaque-pointers -triple csky -target-feature +fpuv2_sf -target-feature +fpuv2_df -target-feature +hard-float-abi -target-feature +hard-float -emit-llvm %s -o - | FileCheck %s
+
+#include 
+
+// Verify that the tracking of used GPRs and FPRs works correctly by checking
+// that small integers are sign/zero extended when passed in registers.
+
+// Doubles are passed in FPRs, so argument 'i' will be passed zero-extended
+// because it will be passed in a GPR.
+
+// CHECK: define{{.*}} void @f_fpr_tracking(double noundef %a, double noundef %b, double noundef %c, double noundef %d, i8 noundef zeroext %i)
+void f_fpr_tracking(double a, double b, double c, double d, uint8_t i) {}
+
+// A struct containing just one floating-point real is passed as though it
+// were a standalone floating-point real.
+struct double_s {
+  double f;
+};
+
+// CHECK: define{{.*}} void @f_double_s_arg(double %a.coerce)
+void f_double_s_arg(struct double_s a) {}
+
+// CHECK: define{{.*}} double @f_ret_double_s()
+struct double_s f_ret_double_s(void) {
+  return (struct double_s){1.0};
+}
+
+// A struct containing a double and any number of zero-width bitfields is
+// passed as though it were a standalone floating-point real.
+
+struct zbf_double_s {
+  int : 0;
+  double f;
+};
+struct zbf_double_zbf_s {
+  int : 0;
+  double f;
+  int : 0;
+};
+
+// CHECK: define{{.*}} void @f_zbf_double_s_arg(double %a.coerce)
+void f_zbf_double_s_arg(struct zbf_double_s a) {}
+
+// CHECK: define{{.*}} double @f_ret_zbf_double_s()
+struct zbf_double_s f_ret_zbf_double_s(void) {
+  return (struct zbf_double_s){1.0};
+}
+
+// CHECK: define{{.*}} void @f_zbf_double_zbf_s_arg(double %a.coerce)
+void f_zbf_double_zbf_s_arg(struct zbf_double_zbf_s a) {}
+
+// CHECK: define{{.*}} double @f_ret_zbf_double_zbf_s()
+struct zbf_double_zbf_s f_ret_zbf_double_zbf_s(void) {
+  return (struct zbf_double_zbf_s){1.0};
+}
+
+// For argument type, the first 4*XLen parts of aggregate will be passed
+// in registers, and the rest will be passed in stack.
+// So we can coerce to integers directly and let backend handle it correctly.
+// For return type, aggregate which <= 2*XLen will be returned in registers.
+// Otherwise, aggregate will be returned indirectly.
+
+struct double_double_s {
+  double f;
+  double g;
+};
+struct double_float_s {
+  double f;
+  float g;
+};
+
+// CHECK: define{{.*}} void @f_double_double_s_arg([4 x i32] %a.coerce)
+void f_double_double_s_arg(struct double_double_s a) {}
+
+// CHECK: define{{.*}} void @f_ret_double_double_s(%struct.double_double_s* noalias sret(%struct.double_double_s) align 4 %agg.result)
+struct double_double_s f_ret_double_double_s(void) {
+  return (struct double_double_s){1.0, 2.0};
+}
+
+// CHECK: define{{.*}} void @f_double_float_s_arg([3 x i32] %a.coerce)
+void f_double_float_s_arg(struct double_float_s a) {}
+
+// CHECK: define{{.*}} void @f_ret_double_float_s(%struct.double_float_s* noalias sret(%struct.double_float_s) align 4 %agg.result)
+struct double_float_s f_ret_double_float_s(void) {
+  return (struct double_float_s){1.0, 2.0};
+}
+
+// CHECK: define{{.*}} void @f_double_double_s_arg_insufficient_fprs(float noundef %a, double noundef %b, double noundef %c, double noundef %d, double noundef %e, double noundef %f, double noundef %g, double noundef %i, [4 x i32] %h.coerce)
+void f_double_double_s_arg_insufficient_fprs(float a, double b, double c, double d,
+ double e, double f, double g, double i, struct double_double_s h) {}
+
+struct double_int8_s {
+  double f;
+  int8_t i;
+};
+struct double_uint8_s {
+  double f;
+  uint8_t i;
+};
+struct double_int32_s {
+  double f;
+  int32_t i;
+};
+struct double_int64_s {
+  double f;
+  int64_t i;
+};
+struct double_int64bf_s {
+  double f;
+  int64_t i : 32;
+};
+struct double_int8_zbf_s {
+  double f;
+  int8_t i;
+  int : 0;
+};
+
+// CHECK: define{{.*}}  @f_double_int8_s_arg([3 x i32] %a.coerce)
+void f_double_int8_s_arg(struct double_int8_s a) {}
+
+// CHECK: define{{.*}} void @f_ret_double_int8_s(%struct.double_int8_s* noalias sret(%struct.double_int8_s) align 4 %agg.result)
+struct double_int8_s f_ret_double_int8_s(void) {
+  return (struct double_int8_s){1.0, 2};
+}
+
+// CHECK: define{{.*}} void @f_double_uint8_s_arg([3 x i32] %a.coerce)
+void f_double_uint8_s_arg(struct double_uint8_s a) {}
+
+// CHECK: define{{.*}} void @f_ret_double_uint8_s(%struct.double_uint8_s* noalias sret(%struct.double_uint8_s) align 4 %agg.result)
+struct doubl

[PATCH] D126451: [Clang][CSKY] Add support about CSKYABIInfo

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D126451#3539512 , @DavidSpickett 
wrote:

> Can you reupload with more context? See 
> https://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface
>
> I doubt I'll be able to give any in depth review but if things look good 
> generally I'm sure you'll find the issues through your own testing as time 
> goes on.

Well, sorry that I forgot to add -U99 option.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126451/new/

https://reviews.llvm.org/D126451

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D126451: [Clang][CSKY] Add support about CSKYABIInfo

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D126451#3539656 , @rengolin wrote:

> This looks good to me, but wait to make sure others see it, too.
>
> My reasons are: it is largely similar to RISCV implementation, it seems to 
> follow what I expected of the ABI (which is similar to other targets) and has 
> a large corpus of tests.
>
> I can't comment on the specifics of the ABI implementation (I haven't read 
> the ABI document *that* thoroughly), but as David said, issues will be picked 
> up by tests until the target reaches maturity.

I don't think it is largely similar to RISCV implementation except for the code 
structure and test reuse. And the test result is big different.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126451/new/

https://reviews.llvm.org/D126451

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D126451: [Clang][CSKY] Add support about CSKYABIInfo

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:11708
+  case llvm::Triple::csky: {
+bool IsSoftFloat = !getTarget().hasFeature("hard-float-abi");
+bool hasFP64 = getTarget().hasFeature("fpuv2_df") ||

DavidSpickett wrote:
> I see a "hard-float" and "hard-float-abi" in this change. Is it safe to check 
> just for "hard-float-abi" here?
> 
> Just checking, I assume it's fine. You could have hardware with hard float 
> but you want to compile for soft float abi. This allows that.
> You could have hardware with hard float but you want to compile for soft 
> float abi. This allows that.

Yes. As you said.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:11710
+bool hasFP64 = getTarget().hasFeature("fpuv2_df") ||
+   getTarget().hasFeature("fpuv3_df");
+return SetCGInfo(new CSKYTargetCodeGenInfo(Types, IsSoftFloat ? 0

DavidSpickett wrote:
> Silly question, was/is there an fpuv1 and was it 32 bit only? (I assume so)
I think fpuv1 is not supported anymore in llvm.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126451/new/

https://reviews.llvm.org/D126451

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D126451: [Clang][CSKY] Add support about CSKYABIInfo

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

BTW, I have run llvm-test-suite, it passed.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126451/new/

https://reviews.llvm.org/D126451

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D126451: [Clang][CSKY] Add support about CSKYABIInfo

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu updated this revision to Diff 432820.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126451/new/

https://reviews.llvm.org/D126451

Files:
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGen/CSKY/csky-abi.c
  clang/test/CodeGen/CSKY/csky-hard-abi.c
  clang/test/CodeGen/CSKY/csky-soft-abi.c

Index: clang/test/CodeGen/CSKY/csky-soft-abi.c
===
--- /dev/null
+++ clang/test/CodeGen/CSKY/csky-soft-abi.c
@@ -0,0 +1,395 @@
+// RUN: %clang_cc1 -no-opaque-pointers -triple csky -target-feature +fpuv2_sf -target-feature +fpuv2_df -target-feature +hard-float -emit-llvm %s -o - | FileCheck %s
+
+#include 
+
+// Verify that the tracking of used GPRs and FPRs works correctly by checking
+// that small integers are sign/zero extended when passed in registers.
+
+// Doubles are passed in FPRs, so argument 'i' will be passed zero-extended
+// because it will be passed in a GPR.
+
+// CHECK: define{{.*}} void @f_fpr_tracking(double noundef %a, double noundef %b, double noundef %c, double noundef %d, i8 noundef zeroext %i)
+void f_fpr_tracking(double a, double b, double c, double d, uint8_t i) {}
+
+// A struct containing just one floating-point real is passed as though it
+// were a standalone floating-point real.
+struct double_s {
+  double f;
+};
+
+// CHECK: define{{.*}} void @f_double_s_arg(double %a.coerce)
+void f_double_s_arg(struct double_s a) {}
+
+// CHECK: define{{.*}} double @f_ret_double_s()
+struct double_s f_ret_double_s(void) {
+  return (struct double_s){1.0};
+}
+
+// A struct containing a double and any number of zero-width bitfields is
+// passed as though it were a standalone floating-point real.
+
+struct zbf_double_s {
+  int : 0;
+  double f;
+};
+struct zbf_double_zbf_s {
+  int : 0;
+  double f;
+  int : 0;
+};
+
+// CHECK: define{{.*}} void @f_zbf_double_s_arg(double %a.coerce)
+void f_zbf_double_s_arg(struct zbf_double_s a) {}
+
+// CHECK: define{{.*}} double @f_ret_zbf_double_s()
+struct zbf_double_s f_ret_zbf_double_s(void) {
+  return (struct zbf_double_s){1.0};
+}
+
+// CHECK: define{{.*}} void @f_zbf_double_zbf_s_arg(double %a.coerce)
+void f_zbf_double_zbf_s_arg(struct zbf_double_zbf_s a) {}
+
+// CHECK: define{{.*}} double @f_ret_zbf_double_zbf_s()
+struct zbf_double_zbf_s f_ret_zbf_double_zbf_s(void) {
+  return (struct zbf_double_zbf_s){1.0};
+}
+
+// For argument type, the first 4*XLen parts of aggregate will be passed
+// in registers, and the rest will be passed in stack.
+// So we can coerce to integers directly and let backend handle it correctly.
+// For return type, aggregate which <= 2*XLen will be returned in registers.
+// Otherwise, aggregate will be returned indirectly.
+
+struct double_double_s {
+  double f;
+  double g;
+};
+struct double_float_s {
+  double f;
+  float g;
+};
+
+// CHECK: define{{.*}} void @f_double_double_s_arg([4 x i32] %a.coerce)
+void f_double_double_s_arg(struct double_double_s a) {}
+
+// CHECK: define{{.*}} void @f_ret_double_double_s(%struct.double_double_s* noalias sret(%struct.double_double_s) align 4 %agg.result)
+struct double_double_s f_ret_double_double_s(void) {
+  return (struct double_double_s){1.0, 2.0};
+}
+
+// CHECK: define{{.*}} void @f_double_float_s_arg([3 x i32] %a.coerce)
+void f_double_float_s_arg(struct double_float_s a) {}
+
+// CHECK: define{{.*}} void @f_ret_double_float_s(%struct.double_float_s* noalias sret(%struct.double_float_s) align 4 %agg.result)
+struct double_float_s f_ret_double_float_s(void) {
+  return (struct double_float_s){1.0, 2.0};
+}
+
+// CHECK: define{{.*}} void @f_double_double_s_arg_insufficient_fprs(float noundef %a, double noundef %b, double noundef %c, double noundef %d, double noundef %e, double noundef %f, double noundef %g, double noundef %i, [4 x i32] %h.coerce)
+void f_double_double_s_arg_insufficient_fprs(float a, double b, double c, double d,
+ double e, double f, double g, double i, struct double_double_s h) {}
+
+struct double_int8_s {
+  double f;
+  int8_t i;
+};
+struct double_uint8_s {
+  double f;
+  uint8_t i;
+};
+struct double_int32_s {
+  double f;
+  int32_t i;
+};
+struct double_int64_s {
+  double f;
+  int64_t i;
+};
+struct double_int64bf_s {
+  double f;
+  int64_t i : 32;
+};
+struct double_int8_zbf_s {
+  double f;
+  int8_t i;
+  int : 0;
+};
+
+// CHECK: define{{.*}}  @f_double_int8_s_arg([3 x i32] %a.coerce)
+void f_double_int8_s_arg(struct double_int8_s a) {}
+
+// CHECK: define{{.*}} void @f_ret_double_int8_s(%struct.double_int8_s* noalias sret(%struct.double_int8_s) align 4 %agg.result)
+struct double_int8_s f_ret_double_int8_s(void) {
+  return (struct double_int8_s){1.0, 2};
+}
+
+// CHECK: define{{.*}} void @f_double_uint8_s_arg([3 x i32] %a.coerce)
+void f_double_uint8_s_arg(struct double_uint8_s a) {}
+
+// CHECK: define{{.*}} void @f_ret_double_uint8_s(%struct.double_uint8_s* noalias sret(%struct.double_uint8_s) align 4 %agg.result)
+st

[PATCH] D126451: [Clang][CSKY] Add support about CSKYABIInfo

[Zixuan Wu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG563cc3fda9a2: [Clang][CSKY] Add support about CSKYABIInfo 
(authored by zixuan-wu).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126451/new/

https://reviews.llvm.org/D126451

Files:
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGen/CSKY/csky-abi.c
  clang/test/CodeGen/CSKY/csky-hard-abi.c
  clang/test/CodeGen/CSKY/csky-soft-abi.c

Index: clang/test/CodeGen/CSKY/csky-soft-abi.c
===
--- /dev/null
+++ clang/test/CodeGen/CSKY/csky-soft-abi.c
@@ -0,0 +1,395 @@
+// RUN: %clang_cc1 -no-opaque-pointers -triple csky -target-feature +fpuv2_sf -target-feature +fpuv2_df -target-feature +hard-float -emit-llvm %s -o - | FileCheck %s
+
+#include 
+
+// Verify that the tracking of used GPRs and FPRs works correctly by checking
+// that small integers are sign/zero extended when passed in registers.
+
+// Doubles are passed in FPRs, so argument 'i' will be passed zero-extended
+// because it will be passed in a GPR.
+
+// CHECK: define{{.*}} void @f_fpr_tracking(double noundef %a, double noundef %b, double noundef %c, double noundef %d, i8 noundef zeroext %i)
+void f_fpr_tracking(double a, double b, double c, double d, uint8_t i) {}
+
+// A struct containing just one floating-point real is passed as though it
+// were a standalone floating-point real.
+struct double_s {
+  double f;
+};
+
+// CHECK: define{{.*}} void @f_double_s_arg(double %a.coerce)
+void f_double_s_arg(struct double_s a) {}
+
+// CHECK: define{{.*}} double @f_ret_double_s()
+struct double_s f_ret_double_s(void) {
+  return (struct double_s){1.0};
+}
+
+// A struct containing a double and any number of zero-width bitfields is
+// passed as though it were a standalone floating-point real.
+
+struct zbf_double_s {
+  int : 0;
+  double f;
+};
+struct zbf_double_zbf_s {
+  int : 0;
+  double f;
+  int : 0;
+};
+
+// CHECK: define{{.*}} void @f_zbf_double_s_arg(double %a.coerce)
+void f_zbf_double_s_arg(struct zbf_double_s a) {}
+
+// CHECK: define{{.*}} double @f_ret_zbf_double_s()
+struct zbf_double_s f_ret_zbf_double_s(void) {
+  return (struct zbf_double_s){1.0};
+}
+
+// CHECK: define{{.*}} void @f_zbf_double_zbf_s_arg(double %a.coerce)
+void f_zbf_double_zbf_s_arg(struct zbf_double_zbf_s a) {}
+
+// CHECK: define{{.*}} double @f_ret_zbf_double_zbf_s()
+struct zbf_double_zbf_s f_ret_zbf_double_zbf_s(void) {
+  return (struct zbf_double_zbf_s){1.0};
+}
+
+// For argument type, the first 4*XLen parts of aggregate will be passed
+// in registers, and the rest will be passed in stack.
+// So we can coerce to integers directly and let backend handle it correctly.
+// For return type, aggregate which <= 2*XLen will be returned in registers.
+// Otherwise, aggregate will be returned indirectly.
+
+struct double_double_s {
+  double f;
+  double g;
+};
+struct double_float_s {
+  double f;
+  float g;
+};
+
+// CHECK: define{{.*}} void @f_double_double_s_arg([4 x i32] %a.coerce)
+void f_double_double_s_arg(struct double_double_s a) {}
+
+// CHECK: define{{.*}} void @f_ret_double_double_s(%struct.double_double_s* noalias sret(%struct.double_double_s) align 4 %agg.result)
+struct double_double_s f_ret_double_double_s(void) {
+  return (struct double_double_s){1.0, 2.0};
+}
+
+// CHECK: define{{.*}} void @f_double_float_s_arg([3 x i32] %a.coerce)
+void f_double_float_s_arg(struct double_float_s a) {}
+
+// CHECK: define{{.*}} void @f_ret_double_float_s(%struct.double_float_s* noalias sret(%struct.double_float_s) align 4 %agg.result)
+struct double_float_s f_ret_double_float_s(void) {
+  return (struct double_float_s){1.0, 2.0};
+}
+
+// CHECK: define{{.*}} void @f_double_double_s_arg_insufficient_fprs(float noundef %a, double noundef %b, double noundef %c, double noundef %d, double noundef %e, double noundef %f, double noundef %g, double noundef %i, [4 x i32] %h.coerce)
+void f_double_double_s_arg_insufficient_fprs(float a, double b, double c, double d,
+ double e, double f, double g, double i, struct double_double_s h) {}
+
+struct double_int8_s {
+  double f;
+  int8_t i;
+};
+struct double_uint8_s {
+  double f;
+  uint8_t i;
+};
+struct double_int32_s {
+  double f;
+  int32_t i;
+};
+struct double_int64_s {
+  double f;
+  int64_t i;
+};
+struct double_int64bf_s {
+  double f;
+  int64_t i : 32;
+};
+struct double_int8_zbf_s {
+  double f;
+  int8_t i;
+  int : 0;
+};
+
+// CHECK: define{{.*}}  @f_double_int8_s_arg([3 x i32] %a.coerce)
+void f_double_int8_s_arg(struct double_int8_s a) {}
+
+// CHECK: define{{.*}} void @f_ret_double_int8_s(%struct.double_int8_s* noalias sret(%struct.double_int8_s) align 4 %agg.result)
+struct double_int8_s f_ret_double_int8_s(void) {
+  return (struct double_int8_s){1.0, 2};
+}
+
+// CHECK: define{{.*}} void @f_double_uint8_s_arg([3 x i32] %a.coerce)
+void f_double_uint8_s_ar

[PATCH] D149017: [RISCV] Rewrite all found class-based subroutines to functions

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

Is it going to commit?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149017/new/

https://reviews.llvm.org/D149017

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D70401: [RISCV] CodeGen of RVE and ilp32e/lp64e ABIs

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

ping?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70401/new/

https://reviews.llvm.org/D70401

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D154588: [CSKY] Optimize implementation of intrinsic 'llvm.cttz.i32'

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: clang/test/CodeGen/CSKY/csky-builtins.c:1
+// RUN: %clang_cc1 -triple csky -emit-llvm -o - %s | FileCheck %s
+

benshi001 wrote:
> This file is pure test, has nothing to do with `llvm.cttz`, just to avoid 
> another patch.
Don't make unrelated patch together in one single commit.



Comment at: clang/test/CodeGen/CSKY/csky-builtins.c:67
+  return __builtin_bswap64(x);
+}

Those are target-independent intrinsics/builtins. I think it's no more need to 
test for specific target such as csky again, unless it's different behavior or 
output.



Comment at: llvm/test/CodeGen/CSKY/intrinsic.ll:36
+define i16 @bswap16(i16 %x) {
+; CHECK-LABEL: bswap16:
+; CHECK:   # %bb.0: # %entry

Again. It's related to cttz?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D154588/new/

https://reviews.llvm.org/D154588

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D154588: [CSKY] Optimize implementation of intrinsic 'llvm.cttz.i32'

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: llvm/test/CodeGen/CSKY/intrinsic.ll:21
+entry:
+  %ntz = call i32 @llvm.cttz.i32(i32 %x, i1 1)
+  ret i32 %ntz

I think we can also test the condition that the second argument is zero.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D154588/new/

https://reviews.llvm.org/D154588

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D156363: [Driver] -###: exit with code 1 if hasErrorOccurred

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: clang/test/Driver/debug-options.c:245
 //
 // RUN: %clang -### -c -gsplit-dwarf -g -gno-pubnames %s 2>&1 | FileCheck 
-check-prefix=NOPUB %s
 //

Here should add not or specify the target with x86 because it fails when only 
RV target is compiled.

```
clang: error: -gsplit-dwarf is unsupported with RISC-V linker relaxation 
(-mrelax)
```


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D156363/new/

https://reviews.llvm.org/D156363

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D156363: [Driver] -###: exit with code 1 if hasErrorOccurred

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.
Herald added a subscriber: sunshaoce.

I am afraid there is also error at clang/test/Driver/as-options.s  when default 
triple is 'riscv32-unknown-elf'


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D156363/new/

https://reviews.llvm.org/D156363

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D70401: [RISCV] CodeGen of RVE and ilp32e/lp64e ABIs

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: llvm/lib/Target/RISCV/RISCVFrameLowering.cpp:908
 
 static const MCPhysReg CSRegs[] = { RISCV::X1,  /* ra */
   RISCV::X5, RISCV::X6, RISCV::X7,  /* t0-t2 */

Hi, @wangpc it's hidden bug that out of range registers are saved/restored in 
prologue/epilogue


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70401/new/

https://reviews.llvm.org/D70401

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D70401: [RISCV] CodeGen of RVE and ilp32e/lp64e ABIs

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: llvm/lib/Target/RISCV/RISCVRegisterInfo.cpp:66
   return CSR_XLEN_F32_Interrupt_SaveList;
 return CSR_Interrupt_SaveList;
   }

Here also need adjust for rve.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70401/new/

https://reviews.llvm.org/D70401

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D129824: [RISCV] Set triple based on -march flag which can be deduced in more generic way

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

Ping.. Do we still prefer to specify target triple explicitly to make a check?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129824/new/

https://reviews.llvm.org/D129824

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D153111: [clang][Serialization][RISCV] Increase the number of reserved predefined type IDs

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

I also caught this issue.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D153111/new/

https://reviews.llvm.org/D153111

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits