[PATCH] D27251: [PPC] some bugs mainly about sign problem fixed in altivec.h

[ZiXuan Wu via Phabricator via cfe-commits]

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

Hi, All.

The revision has been updated, please review it again. 
Thanks a lot.


https://reviews.llvm.org/D27251



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

[PATCH] D27251: [PPC] some bugs mainly about sign problem fixed in altivec.h

[ZiXuan Wu via Phabricator via cfe-commits]

Zeson added a comment.

In https://reviews.llvm.org/D27251#610629, @kbarton wrote:

> Please make explicit the signed for the parameters to the functions you are 
> changing and remove unnecessary casts. I marked the first few that I found, 
> but stopped marking them after the first several.


I think it does not need to make explicit signed for the parameters such as 
making `vector int` to `vector signed int`, making `vector short` to `vector 
signed short`.
The whole file containing lots of such issues can be modified or fixed in 
another single patch to avoid introducing noise in this patch.


https://reviews.llvm.org/D27251



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

[PATCH] D27251: [PPC] some bugs mainly about sign problem fixed in altivec.h

[ZiXuan Wu via Phabricator via cfe-commits]

Zeson updated this revision to Diff 80021.
Zeson marked 3 inline comments as done.
Zeson added a comment.

Remove some unnecessary cast


https://reviews.llvm.org/D27251

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

Index: test/CodeGen/builtins-ppc-vsx.c
===
--- test/CodeGen/builtins-ppc-vsx.c
+++ test/CodeGen/builtins-ppc-vsx.c
@@ -1592,11 +1592,11 @@
 // CHECK: @llvm.ppc.altivec.vsl
 // CHECK-LE: @llvm.ppc.altivec.vsl
 
-res_vull = vec_sll(vull, vuc);
+  res_vull = vec_sll(vull, vuc);
 // CHECK: @llvm.ppc.altivec.vsl
 // CHECK-LE: @llvm.ppc.altivec.vsl
 
-res_vsll = vec_slo(vsll, vsc);
+  res_vsll = vec_slo(vsll, vsc);
 // CHECK: @llvm.ppc.altivec.vslo
 // CHECK-LE: @llvm.ppc.altivec.vslo
 
@@ -1636,59 +1636,134 @@
 // CHECK: @llvm.ppc.altivec.vsro
 // CHECK-LE: @llvm.ppc.altivec.vsro
 
-res_vsll = vec_xl(sll, asll);
+  res_vsll = vec_xl(sll, asll);
 // CHECK: load <2 x i64>, <2 x i64>* %{{[0-9]+}}, align 16
 // CHECK-LE: load <2 x i64>, <2 x i64>* %{{[0-9]+}}, align 16
 
-res_vull = vec_xl(sll, aull);
+  res_vull = vec_xl(sll, aull);
 // CHECK: load <2 x i64>, <2 x i64>* %{{[0-9]+}}, align 16
 // CHECK-LE: load <2 x i64>, <2 x i64>* %{{[0-9]+}}, align 16
 
-res_vd = vec_xl(sll, ad);
+  res_vd = vec_xl(sll, ad);
 // CHECK: load <2 x double>, <2 x double>* %{{[0-9]+}}, align 16
 // CHECK-LE: load <2 x double>, <2 x double>* %{{[0-9]+}}, align 16
 
-vec_xst(vsll, sll, asll);
+  vec_xst(vsll, sll, asll);
 // CHECK: store <2 x i64> %{{[0-9]+}}, <2 x i64>* %{{[0-9]+}}, align 16
 // CHECK-LE: store <2 x i64> %{{[0-9]+}}, <2 x i64>* %{{[0-9]+}}, align 16
 
-vec_xst(vull, sll, aull);
+  vec_xst(vull, sll, aull);
 // CHECK: store <2 x i64> %{{[0-9]+}}, <2 x i64>* %{{[0-9]+}}, align 16
 // CHECK-LE: store <2 x i64> %{{[0-9]+}}, <2 x i64>* %{{[0-9]+}}, align 16
 
-vec_xst(vd, sll, ad);
+  vec_xst(vd, sll, ad);
 // CHECK: store <2 x double> %{{[0-9]+}}, <2 x double>* %{{[0-9]+}}, align 16
 // CHECK-LE: store <2 x double> %{{[0-9]+}}, <2 x double>* %{{[0-9]+}}, align 16
 
-res_vsll = vec_xl_be(sll, asll);
-// CHECK: load <2 x i64>, <2 x i64>* %{{[0-9]+}}, align 16
-// CHECK-LE: call <2 x double> @llvm.ppc.vsx.lxvd2x.be(i8* %{{[0-9]+}})
-
-res_vull = vec_xl_be(sll, aull);
-// CHECK: load <2 x i64>, <2 x i64>* %{{[0-9]+}}, align 16
-// CHECK-LE: call <2 x double> @llvm.ppc.vsx.lxvd2x.be(i8* %{{[0-9]+}})
-
-res_vd = vec_xl_be(sll, ad);
-// CHECK: load <2 x double>, <2 x double>* %{{[0-9]+}}, align 16
-// CHECK-LE: call <2 x double> @llvm.ppc.vsx.lxvd2x.be(i8* %{{[0-9]+}})
-
-vec_xst_be(vsll, sll, asll);
-// CHECK: store <2 x i64> %{{[0-9]+}}, <2 x i64>* %{{[0-9]+}}, align 16
-// CHECK-LE: call void @llvm.ppc.vsx.stxvd2x.be(<2 x double> %{{[0-9]+}}, i8* %{{[0-9]+}})
-
-vec_xst_be(vull, sll, aull);
-// CHECK: store <2 x i64> %{{[0-9]+}}, <2 x i64>* %{{[0-9]+}}, align 16
-// CHECK-LE: call void @llvm.ppc.vsx.stxvd2x.be(<2 x double> %{{[0-9]+}}, i8* %{{[0-9]+}})
-
-vec_xst_be(vd, sll, ad);
-// CHECK: store <2 x double> %{{[0-9]+}}, <2 x double>* %{{[0-9]+}}, align 16
-// CHECK-LE: call void @llvm.ppc.vsx.stxvd2x.be(<2 x double> %{{[0-9]+}}, i8* %{{[0-9]+}})
-
   res_vf = vec_neg(vf);
 // CHECK: fsub <4 x float> , {{%[0-9]+}}
 // CHECK-LE: fsub <4 x float> , {{%[0-9]+}}
 
   res_vd = vec_neg(vd);
 // CHECK: fsub <2 x double> , {{%[0-9]+}}
 // CHECK-LE: fsub <2 x double> , {{%[0-9]+}}
 }
+
+
+/* - vec_xl_be -- */
+void test2() {
+  // CHECK-LABEL: define void @test2
+  // CHECK-LE-LABEL: define void @test2
+  vec_xl_be(sll, asc);
+  // CHECK: load <16 x i8>, <16 x i8>* %{{[0-9]+}}, align 16
+  // CHECK-LE: call <2 x double> @llvm.ppc.vsx.lxvd2x.be(i8* %{{[0-9]+}})
+  // CHECK-LE: shufflevector <16 x i8> %{{[0-9]+}}, <16 x i8> %{{[0-9]+}}, <16 x i32> 
+
+  vec_xl_be(sll, auc);
+  // CHECK: load <16 x i8>, <16 x i8>* %{{[0-9]+}}, align 16
+  // CHECK-LE: call <2 x double> @llvm.ppc.vsx.lxvd2x.be(i8* %{{[0-9]+}})
+  // CHECK-LE: shufflevector <16 x i8> %{{[0-9]+}}, <16 x i8> %{{[0-9]+}}, <16 x i32> 
+
+  vec_xl_be(sll, ass);
+  // CHECK: load <8 x i16>, <8 x i16>* %{{[0-9]+}}, align 16
+  // CHECK-LE: call <2 x double> @llvm.ppc.vsx.lxvd2x.be(i8* %{{[0-9]+}})
+  // CHECK-LE: shufflevector <8 x i16> %{{[0-9]+}}, <8 x i16> %{{[0-9]+}}, <8 x i32> 
+
+  vec_xl_be(sll, aus);
+  // CHECK: load <8 x i16>, <8 x i16>* %{{[0-9]+}}, align 16
+  // CHECK-LE: call <2 x double> @llvm.ppc.vsx.lxvd2x.be(i8* %{{[0-9]+}})
+  // CHECK-LE: shufflevector <8 x i16> %{{[0-9]+}}, <8 x i16> %{{[0-9]+}}, <8 x i32> 
+
+  vec_xl_be(sll, asi);
+  // CHECK: load <4 x i32>, <4 x i32>* %{{[0-9]+}}, align 16
+  // CHECK-LE: call <4 x i32> @llvm.ppc.vsx.lxvw4x.be(i8* %{{[0-9]+}})
+
+  vec_xl_be(sll, aui);
+  // CHECK: load <4 x i32>, <4 x i32>* %{{[0-9]+}}, align 16
+  // CHECK-LE: call <4 x i32> @llvm.ppc.vsx.lxvw4x.be(i8* %{{[0-9]+}})
+
+  

[PATCH] D27251: [PPC] some bugs mainly about sign problem fixed in altivec.h

[ZiXuan Wu via Phabricator via cfe-commits]

Zeson updated this revision to Diff 79856.
Zeson added a comment.

Make vec_xst_be and vec_xl_be test cases put together seperately in 
`builtins-ppc-vsx.c`
Move up macro `__VSX__` to make all vec_xst_be functions included


https://reviews.llvm.org/D27251

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

Index: test/CodeGen/builtins-ppc-vsx.c
===
--- test/CodeGen/builtins-ppc-vsx.c
+++ test/CodeGen/builtins-ppc-vsx.c
@@ -1592,11 +1592,11 @@
 // CHECK: @llvm.ppc.altivec.vsl
 // CHECK-LE: @llvm.ppc.altivec.vsl
 
-res_vull = vec_sll(vull, vuc);
+  res_vull = vec_sll(vull, vuc);
 // CHECK: @llvm.ppc.altivec.vsl
 // CHECK-LE: @llvm.ppc.altivec.vsl
 
-res_vsll = vec_slo(vsll, vsc);
+  res_vsll = vec_slo(vsll, vsc);
 // CHECK: @llvm.ppc.altivec.vslo
 // CHECK-LE: @llvm.ppc.altivec.vslo
 
@@ -1636,59 +1636,134 @@
 // CHECK: @llvm.ppc.altivec.vsro
 // CHECK-LE: @llvm.ppc.altivec.vsro
 
-res_vsll = vec_xl(sll, asll);
+  res_vsll = vec_xl(sll, asll);
 // CHECK: load <2 x i64>, <2 x i64>* %{{[0-9]+}}, align 16
 // CHECK-LE: load <2 x i64>, <2 x i64>* %{{[0-9]+}}, align 16
 
-res_vull = vec_xl(sll, aull);
+  res_vull = vec_xl(sll, aull);
 // CHECK: load <2 x i64>, <2 x i64>* %{{[0-9]+}}, align 16
 // CHECK-LE: load <2 x i64>, <2 x i64>* %{{[0-9]+}}, align 16
 
-res_vd = vec_xl(sll, ad);
+  res_vd = vec_xl(sll, ad);
 // CHECK: load <2 x double>, <2 x double>* %{{[0-9]+}}, align 16
 // CHECK-LE: load <2 x double>, <2 x double>* %{{[0-9]+}}, align 16
 
-vec_xst(vsll, sll, asll);
+  vec_xst(vsll, sll, asll);
 // CHECK: store <2 x i64> %{{[0-9]+}}, <2 x i64>* %{{[0-9]+}}, align 16
 // CHECK-LE: store <2 x i64> %{{[0-9]+}}, <2 x i64>* %{{[0-9]+}}, align 16
 
-vec_xst(vull, sll, aull);
+  vec_xst(vull, sll, aull);
 // CHECK: store <2 x i64> %{{[0-9]+}}, <2 x i64>* %{{[0-9]+}}, align 16
 // CHECK-LE: store <2 x i64> %{{[0-9]+}}, <2 x i64>* %{{[0-9]+}}, align 16
 
-vec_xst(vd, sll, ad);
+  vec_xst(vd, sll, ad);
 // CHECK: store <2 x double> %{{[0-9]+}}, <2 x double>* %{{[0-9]+}}, align 16
 // CHECK-LE: store <2 x double> %{{[0-9]+}}, <2 x double>* %{{[0-9]+}}, align 16
 
-res_vsll = vec_xl_be(sll, asll);
-// CHECK: load <2 x i64>, <2 x i64>* %{{[0-9]+}}, align 16
-// CHECK-LE: call <2 x double> @llvm.ppc.vsx.lxvd2x.be(i8* %{{[0-9]+}})
-
-res_vull = vec_xl_be(sll, aull);
-// CHECK: load <2 x i64>, <2 x i64>* %{{[0-9]+}}, align 16
-// CHECK-LE: call <2 x double> @llvm.ppc.vsx.lxvd2x.be(i8* %{{[0-9]+}})
-
-res_vd = vec_xl_be(sll, ad);
-// CHECK: load <2 x double>, <2 x double>* %{{[0-9]+}}, align 16
-// CHECK-LE: call <2 x double> @llvm.ppc.vsx.lxvd2x.be(i8* %{{[0-9]+}})
-
-vec_xst_be(vsll, sll, asll);
-// CHECK: store <2 x i64> %{{[0-9]+}}, <2 x i64>* %{{[0-9]+}}, align 16
-// CHECK-LE: call void @llvm.ppc.vsx.stxvd2x.be(<2 x double> %{{[0-9]+}}, i8* %{{[0-9]+}})
-
-vec_xst_be(vull, sll, aull);
-// CHECK: store <2 x i64> %{{[0-9]+}}, <2 x i64>* %{{[0-9]+}}, align 16
-// CHECK-LE: call void @llvm.ppc.vsx.stxvd2x.be(<2 x double> %{{[0-9]+}}, i8* %{{[0-9]+}})
-
-vec_xst_be(vd, sll, ad);
-// CHECK: store <2 x double> %{{[0-9]+}}, <2 x double>* %{{[0-9]+}}, align 16
-// CHECK-LE: call void @llvm.ppc.vsx.stxvd2x.be(<2 x double> %{{[0-9]+}}, i8* %{{[0-9]+}})
-
   res_vf = vec_neg(vf);
 // CHECK: fsub <4 x float> , {{%[0-9]+}}
 // CHECK-LE: fsub <4 x float> , {{%[0-9]+}}
 
   res_vd = vec_neg(vd);
 // CHECK: fsub <2 x double> , {{%[0-9]+}}
 // CHECK-LE: fsub <2 x double> , {{%[0-9]+}}
 }
+
+
+/* - vec_xl_be -- */
+void test2() {
+  // CHECK-LABEL: define void @test2
+  // CHECK-LE-LABEL: define void @test2
+  vec_xl_be(sll, asc);
+  // CHECK: load <16 x i8>, <16 x i8>* %{{[0-9]+}}, align 16
+  // CHECK-LE: call <2 x double> @llvm.ppc.vsx.lxvd2x.be(i8* %{{[0-9]+}})
+  // CHECK-LE: shufflevector <16 x i8> %{{[0-9]+}}, <16 x i8> %{{[0-9]+}}, <16 x i32> 
+
+  vec_xl_be(sll, auc);
+  // CHECK: load <16 x i8>, <16 x i8>* %{{[0-9]+}}, align 16
+  // CHECK-LE: call <2 x double> @llvm.ppc.vsx.lxvd2x.be(i8* %{{[0-9]+}})
+  // CHECK-LE: shufflevector <16 x i8> %{{[0-9]+}}, <16 x i8> %{{[0-9]+}}, <16 x i32> 
+
+  vec_xl_be(sll, ass);
+  // CHECK: load <8 x i16>, <8 x i16>* %{{[0-9]+}}, align 16
+  // CHECK-LE: call <2 x double> @llvm.ppc.vsx.lxvd2x.be(i8* %{{[0-9]+}})
+  // CHECK-LE: shufflevector <8 x i16> %{{[0-9]+}}, <8 x i16> %{{[0-9]+}}, <8 x i32> 
+
+  vec_xl_be(sll, aus);
+  // CHECK: load <8 x i16>, <8 x i16>* %{{[0-9]+}}, align 16
+  // CHECK-LE: call <2 x double> @llvm.ppc.vsx.lxvd2x.be(i8* %{{[0-9]+}})
+  // CHECK-LE: shufflevector <8 x i16> %{{[0-9]+}}, <8 x i16> %{{[0-9]+}}, <8 x i32> 
+
+  vec_xl_be(sll, asi);
+  // CHECK: load <4 x i32>, <4 x i32>* %{{[0-9]+}}, align 16
+  // CHECK-LE: call <4 x i32> @llvm.ppc.vsx.lxvw4x.be(i8* %{{[0-9]+}})
+
+  vec_xl_be(sll, aui);
+  // CHECK: load <4 x i32>, <4 x i32>* %{{[0-9]+}}, 

[PATCH] D27251: [PPC] some bugs mainly about sign problem fixed in altivec.h

[ZiXuan Wu via Phabricator via cfe-commits]

Zeson added a comment.

In https://reviews.llvm.org/D27251#609014, @nemanjai wrote:

> Thank you for fixing these issues. I certainly see how the shifts really need 
> to get the signedness right because the right shifts need to fill with the 
> sign bit (so that vector bool will still have all 0 or all 1 bits). However, 
> I don't really follow why the comparisons need to be signed. Could you just 
> elaborate a bit on that?
>  Other than satisfying my curiosity on that, this LGTM.


In my opinion, from the table in the PDF above, it seems that vector bool would 
be treated as unsigned or signed depending on the other argument type and it 
would be mapped to related machine instruction. As machine instruction, it is 
just treated as signed or unsigned operand.
F2627693: Screen Shot 2016-11-30 at 9.54.40 PM.png 



https://reviews.llvm.org/D27251



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

[PATCH] D27251: [PPC] some bugs mainly about sign problem fixed in altivec.h

[ZiXuan Wu via Phabricator via cfe-commits]

Zeson abandoned this revision.
Zeson added a comment.

I think this revision is out-of-date. I'd like to abandon it.


https://reviews.llvm.org/D27251



___
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 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 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 

[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 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 =
+  [](const StandardConversionSequence ,
+   const 

[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][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  = f1(c16);
> > > > >   float  = 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 what your 

[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  = f1(c16);
> > > > > > >   float  = 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] 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  = f1(c16);
  float  = 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  = f1(c16);
> >   float  = 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 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 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=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] 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=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] 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]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=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 (char16); // expected-note 2{{candidate function}}
-float (longlong16); // expected-note 2{{candidate function}}
+int (char16);
+float (longlong16);
 
 void f1_test(char16 c16, longlong16 ll16, char16_e c16e, longlong16_e ll16e) {
   int  = f1(c16);
   float  = f1(ll16);
-  f1(c16e); // expected-error{{call to 'f1' is ambiguous}}
-  f1(ll16e); // expected-error{{call to 'f1' is ambiguous}}
+  int  = f1(c16e);
+  float  = 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 char 

[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 (char16); // expected-note 2{{candidate function}}
-float (longlong16); // expected-note 2{{candidate function}}
+int (char16);
+float (longlong16);
 
 void f1_test(char16 c16, longlong16 ll16, char16_e c16e, longlong16_e ll16e) {
   int  = f1(c16);
   float  = f1(ll16);
-  f1(c16e); // expected-error{{call to 'f1' is ambiguous}}
-  f1(ll16e); // expected-error{{call to 'f1' is ambiguous}}
+  int  = f1(c16e);
+  float  = 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 av14;
+
+  __v16sc *gv1_p = 

[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  = 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][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 (char16); // expected-note 2{{candidate function}}
-float (longlong16); // expected-note 2{{candidate function}}
+int (char16);
+float (longlong16);
 
 void f1_test(char16 c16, longlong16 ll16, char16_e c16e, longlong16_e ll16e) {
   int  = f1(c16);
   float  = 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);
+  convert1(gv6);
+  

[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] 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>
-// 

[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  = f1(c16);
> > > > > > > > >   float  = 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] 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] 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] 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
+++ 

[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

[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

[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] D105168: [RISCV] Unify the arch string parsing logic to RISCVISAInfo.

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: llvm/lib/Target/RISCV/MCTargetDesc/RISCVBaseInfo.cpp:107
+  for (auto Feature : RISCVFeatureKV) {
+if (FeatureBits[Feature.Value] &&
+llvm::RISCVISAInfo::isSupportedExtensionFeature(Feature.Key))

If SubtargetFeature is enum value like ARM.td does, Feature.Value would be a 
uninitialization value, so I think there should be if condition like  
`Feature.Value < RISCV::NumSubtargetFeatures`, or there is a out-of-range visit.

```
def ProcXXX :
  SubtargetFeature<"", "RISCVProcFamily",
   "XXX", "XXX processors">;
```


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] D70401: [WIP][RISCV] Implement ilp32e ABI

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D70401#3172750 , @khchen wrote:

> In D70401#3172457 , @zixuan-wu wrote:
>
>> Hi, all. Why is it not continued?
>
> Sorry, I have to work on other tasks so stop the rv32e implementation work.
> Are you interest to finish it? I could share my patches to you.

Is it (D70401 ) good enough to solve or 
complete rv32e issue?


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] D115923: [RISCV][Don't Commit] Refactor the RISCV ISA extension info and target features to support multiple extension version

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu created this revision.
zixuan-wu added reviewers: asb, craig.topper, kito-cheng, luismarques, apazos, 
jrtc27, Jim, akuegel, jhenderson, MaskRay, sjarus.
Herald added subscribers: VincentWu, luke957, achieveartificialintelligence, 
vkmr, frasercrmck, evandro, sameer.abuasal, s.egerton, benna, psnobl, jocewei, 
PkmX, the_o, brucehoult, MartinMosbeck, rogfer01, edward-jones, zzheng, niosHD, 
sabuasal, simoncook, johnrusso, rbar, hiraditya.
zixuan-wu requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

Split from https://reviews.llvm.org/D115921 since testcase change is too large 
to review.

This is part of D115921 , and will not be 
committed.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D115923

Files:
  clang/include/clang/Basic/BuiltinsRISCV.def
  clang/lib/Basic/Targets/RISCV.cpp
  clang/lib/Driver/ToolChains/Arch/RISCV.cpp
  clang/utils/TableGen/RISCVVEmitter.cpp
  llvm/include/llvm/Support/RISCVISAInfo.h
  llvm/lib/Object/ELFObjectFile.cpp
  llvm/lib/Support/RISCVISAInfo.cpp
  llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
  llvm/lib/Target/RISCV/RISCV.td
  llvm/lib/Target/RISCV/RISCVSubtarget.h

Index: llvm/lib/Target/RISCV/RISCVSubtarget.h
===
--- llvm/lib/Target/RISCV/RISCVSubtarget.h
+++ llvm/lib/Target/RISCV/RISCVSubtarget.h
@@ -24,6 +24,7 @@
 #include "llvm/CodeGen/SelectionDAGTargetInfo.h"
 #include "llvm/CodeGen/TargetSubtargetInfo.h"
 #include "llvm/IR/DataLayout.h"
+#include "llvm/Support/RISCVISAInfo.h"
 #include "llvm/Target/TargetMachine.h"
 
 #define GET_SUBTARGETINFO_HEADER
@@ -34,28 +35,28 @@
 
 class RISCVSubtarget : public RISCVGenSubtargetInfo {
   virtual void anchor();
-  bool HasStdExtM = false;
-  bool HasStdExtA = false;
-  bool HasStdExtF = false;
-  bool HasStdExtD = false;
-  bool HasStdExtC = false;
-  bool HasStdExtZba = false;
-  bool HasStdExtZbb = false;
-  bool HasStdExtZbc = false;
-  bool HasStdExtZbe = false;
-  bool HasStdExtZbf = false;
-  bool HasStdExtZbm = false;
-  bool HasStdExtZbp = false;
-  bool HasStdExtZbr = false;
-  bool HasStdExtZbs = false;
-  bool HasStdExtZbt = false;
-  bool HasStdExtV = false;
-  bool HasStdExtZvlsseg = false;
-  bool HasStdExtZvamo = false;
-  bool HasStdExtZfhmin = false;
-  bool HasStdExtZfh = false;
+  RISCVExtensionVersion StdExtM = {0, 0};
+  RISCVExtensionVersion StdExtA = {0, 0};
+  RISCVExtensionVersion StdExtF = {0, 0};
+  RISCVExtensionVersion StdExtD = {0, 0};
+  RISCVExtensionVersion StdExtC = {0, 0};
+  RISCVExtensionVersion StdExtZba = {0, 0};
+  RISCVExtensionVersion StdExtZbb = {0, 0};
+  RISCVExtensionVersion StdExtZbc = {0, 0};
+  RISCVExtensionVersion StdExtZbe = {0, 0};
+  RISCVExtensionVersion StdExtZbf = {0, 0};
+  RISCVExtensionVersion StdExtZbm = {0, 0};
+  RISCVExtensionVersion StdExtZbp = {0, 0};
+  RISCVExtensionVersion StdExtZbr = {0, 0};
+  RISCVExtensionVersion StdExtZbs = {0, 0};
+  RISCVExtensionVersion StdExtZbt = {0, 0};
+  RISCVExtensionVersion StdExtV = {0, 0};
+  RISCVExtensionVersion StdExtZvlsseg = {0, 0};
+  RISCVExtensionVersion StdExtZvamo = {0, 0};
+  RISCVExtensionVersion StdExtZfhmin = {0, 0};
+  RISCVExtensionVersion StdExtZfh = {0, 0};
+  RISCVExtensionVersion StdExtE = {0, 0};
   bool HasRV64 = false;
-  bool IsRV32E = false;
   bool EnableLinkerRelax = false;
   bool EnableRVCHintInstrs = true;
   bool EnableSaveRestore = false;
@@ -101,28 +102,34 @@
 return 
   }
   bool enableMachineScheduler() const override { return true; }
-  bool hasStdExtM() const { return HasStdExtM; }
-  bool hasStdExtA() const { return HasStdExtA; }
-  bool hasStdExtF() const { return HasStdExtF; }
-  bool hasStdExtD() const { return HasStdExtD; }
-  bool hasStdExtC() const { return HasStdExtC; }
-  bool hasStdExtZba() const { return HasStdExtZba; }
-  bool hasStdExtZbb() const { return HasStdExtZbb; }
-  bool hasStdExtZbc() const { return HasStdExtZbc; }
-  bool hasStdExtZbe() const { return HasStdExtZbe; }
-  bool hasStdExtZbf() const { return HasStdExtZbf; }
-  bool hasStdExtZbm() const { return HasStdExtZbm; }
-  bool hasStdExtZbp() const { return HasStdExtZbp; }
-  bool hasStdExtZbr() const { return HasStdExtZbr; }
-  bool hasStdExtZbs() const { return HasStdExtZbs; }
-  bool hasStdExtZbt() const { return HasStdExtZbt; }
-  bool hasStdExtV() const { return HasStdExtV; }
-  bool hasStdExtZvlsseg() const { return HasStdExtZvlsseg; }
-  bool hasStdExtZvamo() const { return HasStdExtZvamo; }
-  bool hasStdExtZfhmin() const { return HasStdExtZfhmin; }
-  bool hasStdExtZfh() const { return HasStdExtZfh; }
+  bool hasStdExtM() const { return StdExtM != RISCVExtensionVersion{0, 0}; }
+  bool hasStdExtA() const { return StdExtA != RISCVExtensionVersion{0, 0}; }
+  bool hasStdExtF() const { return StdExtF != RISCVExtensionVersion{0, 0}; }
+  bool hasStdExtD() const { return StdExtD != 

[PATCH] D115921: [RISCV] Refactor the RISCV ISA extension info and target features to support multiple extension version

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D115921#3201346 , @luismarques 
wrote:

>> enable 'm' extension with passing mattr=+m After this patch, it would be 
>> -mattr=+m2p0.
>
> It's not obvious to me that support for extension versions should mean or has 
> to mean that we always explicitly specify the version. Why can't we keep 
> supporting the option `mattr=+m`, which would be mapped to `mattr=+m,+m2p0`, 
> or whatever the current default `m` version happens to be?

OK. I think default version mattr is acceptable. And then testcases change 
would be clean and simple.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115921

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

[PATCH] D115921: [RISCV] Refactor the RISCV ISA extension info and target features to support multiple extension version

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: llvm/include/llvm/Support/RISCVISAInfo.h:33
+  bool operator!=(const RISCVExtensionVersion ) const {
+return !operator==(Version);
+  }

craig.topper wrote:
> Use `!(*this == Version)`
Good taste.



Comment at: llvm/lib/Target/RISCV/RISCVSubtarget.cpp:91
 StringRef ABIName) {
+  initializeEnvironment();
   // Determine default and user-specified characteristics

craig.topper wrote:
> Why do we need to initialize things now but didn't before?
After the constructor is workable to initialize, no need for 
initializeEnvironment. So remove it.


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

https://reviews.llvm.org/D115921

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

[PATCH] D115921: [RISCV] Refactor the RISCV ISA extension info and target features to support multiple extension version

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu updated this revision to Diff 396147.
zixuan-wu edited the summary of this revision.
zixuan-wu added a comment.

Address all comments.


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

https://reviews.llvm.org/D115921

Files:
  clang/lib/Basic/Targets/RISCV.cpp
  clang/lib/Driver/ToolChains/Arch/RISCV.cpp
  clang/test/Driver/riscv-arch-version.c
  llvm/include/llvm/Support/RISCVISAInfo.h
  llvm/lib/Object/ELFObjectFile.cpp
  llvm/lib/Support/RISCVISAInfo.cpp
  llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
  llvm/lib/Target/RISCV/RISCV.td
  llvm/lib/Target/RISCV/RISCVSubtarget.cpp
  llvm/lib/Target/RISCV/RISCVSubtarget.h
  llvm/test/CodeGen/RISCV/attributes-version.ll
  llvm/test/tools/llvm-objdump/ELF/RISCV/unknown-arch-attr.test

Index: llvm/test/tools/llvm-objdump/ELF/RISCV/unknown-arch-attr.test
===
--- llvm/test/tools/llvm-objdump/ELF/RISCV/unknown-arch-attr.test
+++ llvm/test/tools/llvm-objdump/ELF/RISCV/unknown-arch-attr.test
@@ -3,7 +3,7 @@
 ## The expected behavior is to ignore the unrecognized arch feature and
 ## continue to process the following arch features.
 ##
-## The object file has the "rv32i2p0_x1p0_m2p0" arch feature. "x1p0" is an
+## The object file has the "rv32i2p0_y1p0_m2p0" arch feature. "y1p0" is an
 ## unrecognized architecture extension. llvm-objdump will ignore it and decode
 ## "mul" instruction correctly according to "m2p0" in the arch feature.
 ##
@@ -34,5 +34,5 @@
 Content: 3385C502
   - Name:.riscv.attributes
 Type:SHT_RISCV_ATTRIBUTES
-## The content is the encoding of the arch feature "rv32i2p0_x1p0_m2p0"
-Content: 4123007269736376000119000572763332693270305F783170305F6D32703000
+## The content is the encoding of the arch feature "rv32i2p0_y1p0_m2p0"
+Content: 4123007269736376000119000572763332693270305F793170305F6D32703000
Index: llvm/test/CodeGen/RISCV/attributes-version.ll
===
--- /dev/null
+++ llvm/test/CodeGen/RISCV/attributes-version.ll
@@ -0,0 +1,81 @@
+; Generate ELF attributes from llc.
+
+; RUN: llc -mtriple=riscv32 -mattr=+m %s -o - | FileCheck --check-prefix=RV32M %s
+; RUN: llc -mtriple=riscv32 -mattr=+a %s -o - | FileCheck --check-prefix=RV32A %s
+; RUN: llc -mtriple=riscv32 -mattr=+f %s -o - | FileCheck --check-prefix=RV32F %s
+; RUN: llc -mtriple=riscv32 -mattr=+d %s -o - | FileCheck --check-prefix=RV32D %s
+; RUN: llc -mtriple=riscv32 -mattr=+c %s -o - | FileCheck --check-prefix=RV32C %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zfhmin %s -o - | FileCheck --check-prefix=RV32ZFHMIN %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zfh %s -o - | FileCheck --check-prefix=RV32ZFH %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zba %s -o - | FileCheck --check-prefix=RV32ZBA %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbb %s -o - | FileCheck --check-prefix=RV32ZBB %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbc %s -o - | FileCheck --check-prefix=RV32ZBC %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbe %s -o - | FileCheck --check-prefix=RV32ZBE %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbf %s -o - | FileCheck --check-prefix=RV32ZBF %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbm %s -o - | FileCheck --check-prefix=RV32ZBM %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbp %s -o - | FileCheck --check-prefix=RV32ZBP %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbr %s -o - | FileCheck --check-prefix=RV32ZBR %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbs %s -o - | FileCheck --check-prefix=RV32ZBS %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbt %s -o - | FileCheck --check-prefix=RV32ZBT %s
+
+
+; RV32M: .attribute 5, "rv32i2p0_m2p0"
+; RV32A: .attribute 5, "rv32i2p0_a2p0"
+; RV32F: .attribute 5, "rv32i2p0_f2p0"
+; RV32D: .attribute 5, "rv32i2p0_f2p0_d2p0"
+; RV32C: .attribute 5, "rv32i2p0_c2p0"
+; RV32V: .attribute 5, "rv32i2p0_v0p10_zvlsseg0p10"
+; RV32ZFHMIN: .attribute 5, "rv32i2p0_f2p0_zfhmin0p1"
+; RV32ZFH: .attribute 5, "rv32i2p0_f2p0_zfh0p1_zfhmin0p1"
+; RV32ZBA: .attribute 5, "rv32i2p0_zba1p0"
+; RV32ZBB: .attribute 5, "rv32i2p0_zbb1p0"
+; RV32ZBC: .attribute 5, "rv32i2p0_zbc1p0"
+; RV32ZBE: .attribute 5, "rv32i2p0_zbe0p93"
+; RV32ZBF: .attribute 5, "rv32i2p0_zbf0p93"
+; RV32ZBM: .attribute 5, "rv32i2p0_zbm0p93"
+; RV32ZBP: .attribute 5, "rv32i2p0_zbp0p93"
+; RV32ZBR: .attribute 5, "rv32i2p0_zbr0p93"
+; RV32ZBS: .attribute 5, "rv32i2p0_zbs1p0"
+; RV32ZBT: .attribute 5, "rv32i2p0_zbt0p93"
+
+
+; RUN: llc -mtriple=riscv32 -mattr=+m0p7 < %s 2>&1 | FileCheck --check-prefix=RV32M0P7 %s
+; RUN: llc -mtriple=riscv32 -mattr=+a0p7 < %s 2>&1 | FileCheck --check-prefix=RV32A0P7 %s
+; RUN: llc -mtriple=riscv32 -mattr=+f0p7 < %s 2>&1 | FileCheck --check-prefix=RV32F0P7 %s
+; RUN: llc -mtriple=riscv32 -mattr=+d0p7 < %s 2>&1 | FileCheck --check-prefix=RV32D0P7 %s
+; RUN: llc 

[PATCH] D115921: [RISCV] Refactor the RISCV ISA extension info and target features to support multiple extension version

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu updated this revision to Diff 396148.

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

https://reviews.llvm.org/D115921

Files:
  clang/lib/Basic/Targets/RISCV.cpp
  clang/lib/Driver/ToolChains/Arch/RISCV.cpp
  clang/test/Driver/riscv-arch-version.c
  llvm/include/llvm/Support/RISCVISAInfo.h
  llvm/lib/Object/ELFObjectFile.cpp
  llvm/lib/Support/RISCVISAInfo.cpp
  llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
  llvm/lib/Target/RISCV/RISCV.td
  llvm/lib/Target/RISCV/RISCVSubtarget.h
  llvm/test/CodeGen/RISCV/attributes-version.ll
  llvm/test/tools/llvm-objdump/ELF/RISCV/unknown-arch-attr.test

Index: llvm/test/tools/llvm-objdump/ELF/RISCV/unknown-arch-attr.test
===
--- llvm/test/tools/llvm-objdump/ELF/RISCV/unknown-arch-attr.test
+++ llvm/test/tools/llvm-objdump/ELF/RISCV/unknown-arch-attr.test
@@ -3,7 +3,7 @@
 ## The expected behavior is to ignore the unrecognized arch feature and
 ## continue to process the following arch features.
 ##
-## The object file has the "rv32i2p0_x1p0_m2p0" arch feature. "x1p0" is an
+## The object file has the "rv32i2p0_y1p0_m2p0" arch feature. "y1p0" is an
 ## unrecognized architecture extension. llvm-objdump will ignore it and decode
 ## "mul" instruction correctly according to "m2p0" in the arch feature.
 ##
@@ -34,5 +34,5 @@
 Content: 3385C502
   - Name:.riscv.attributes
 Type:SHT_RISCV_ATTRIBUTES
-## The content is the encoding of the arch feature "rv32i2p0_x1p0_m2p0"
-Content: 4123007269736376000119000572763332693270305F783170305F6D32703000
+## The content is the encoding of the arch feature "rv32i2p0_y1p0_m2p0"
+Content: 4123007269736376000119000572763332693270305F793170305F6D32703000
Index: llvm/test/CodeGen/RISCV/attributes-version.ll
===
--- /dev/null
+++ llvm/test/CodeGen/RISCV/attributes-version.ll
@@ -0,0 +1,81 @@
+; Generate ELF attributes from llc.
+
+; RUN: llc -mtriple=riscv32 -mattr=+m %s -o - | FileCheck --check-prefix=RV32M %s
+; RUN: llc -mtriple=riscv32 -mattr=+a %s -o - | FileCheck --check-prefix=RV32A %s
+; RUN: llc -mtriple=riscv32 -mattr=+f %s -o - | FileCheck --check-prefix=RV32F %s
+; RUN: llc -mtriple=riscv32 -mattr=+d %s -o - | FileCheck --check-prefix=RV32D %s
+; RUN: llc -mtriple=riscv32 -mattr=+c %s -o - | FileCheck --check-prefix=RV32C %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zfhmin %s -o - | FileCheck --check-prefix=RV32ZFHMIN %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zfh %s -o - | FileCheck --check-prefix=RV32ZFH %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zba %s -o - | FileCheck --check-prefix=RV32ZBA %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbb %s -o - | FileCheck --check-prefix=RV32ZBB %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbc %s -o - | FileCheck --check-prefix=RV32ZBC %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbe %s -o - | FileCheck --check-prefix=RV32ZBE %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbf %s -o - | FileCheck --check-prefix=RV32ZBF %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbm %s -o - | FileCheck --check-prefix=RV32ZBM %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbp %s -o - | FileCheck --check-prefix=RV32ZBP %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbr %s -o - | FileCheck --check-prefix=RV32ZBR %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbs %s -o - | FileCheck --check-prefix=RV32ZBS %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbt %s -o - | FileCheck --check-prefix=RV32ZBT %s
+
+
+; RV32M: .attribute 5, "rv32i2p0_m2p0"
+; RV32A: .attribute 5, "rv32i2p0_a2p0"
+; RV32F: .attribute 5, "rv32i2p0_f2p0"
+; RV32D: .attribute 5, "rv32i2p0_f2p0_d2p0"
+; RV32C: .attribute 5, "rv32i2p0_c2p0"
+; RV32V: .attribute 5, "rv32i2p0_v0p10_zvlsseg0p10"
+; RV32ZFHMIN: .attribute 5, "rv32i2p0_f2p0_zfhmin0p1"
+; RV32ZFH: .attribute 5, "rv32i2p0_f2p0_zfh0p1_zfhmin0p1"
+; RV32ZBA: .attribute 5, "rv32i2p0_zba1p0"
+; RV32ZBB: .attribute 5, "rv32i2p0_zbb1p0"
+; RV32ZBC: .attribute 5, "rv32i2p0_zbc1p0"
+; RV32ZBE: .attribute 5, "rv32i2p0_zbe0p93"
+; RV32ZBF: .attribute 5, "rv32i2p0_zbf0p93"
+; RV32ZBM: .attribute 5, "rv32i2p0_zbm0p93"
+; RV32ZBP: .attribute 5, "rv32i2p0_zbp0p93"
+; RV32ZBR: .attribute 5, "rv32i2p0_zbr0p93"
+; RV32ZBS: .attribute 5, "rv32i2p0_zbs1p0"
+; RV32ZBT: .attribute 5, "rv32i2p0_zbt0p93"
+
+
+; RUN: llc -mtriple=riscv32 -mattr=+m0p7 < %s 2>&1 | FileCheck --check-prefix=RV32M0P7 %s
+; RUN: llc -mtriple=riscv32 -mattr=+a0p7 < %s 2>&1 | FileCheck --check-prefix=RV32A0P7 %s
+; RUN: llc -mtriple=riscv32 -mattr=+f0p7 < %s 2>&1 | FileCheck --check-prefix=RV32F0P7 %s
+; RUN: llc -mtriple=riscv32 -mattr=+d0p7 < %s 2>&1 | FileCheck --check-prefix=RV32D0P7 %s
+; RUN: llc -mtriple=riscv32 -mattr=+c0p7 < %s 2>&1 | FileCheck --check-prefix=RV32C0P7 %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zfhmin0p7 < %s 2>&1 

[PATCH] D95589: [RISCV] Support experimental 'P' extension 0.9

[Zixuan Wu via Phabricator via cfe-commits]

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

Could abandon it due to D108189 ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95589

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

[PATCH] D115921: [RISCV] Refactor the RISCV ISA extension info and target features to support multiple extension version

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu updated this revision to Diff 395803.
zixuan-wu edited the summary of this revision.
zixuan-wu added a comment.

Address comments.


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

https://reviews.llvm.org/D115921

Files:
  clang/lib/Basic/Targets/RISCV.cpp
  clang/lib/Driver/ToolChains/Arch/RISCV.cpp
  clang/test/Driver/riscv-arch.c
  llvm/include/llvm/Support/RISCVISAInfo.h
  llvm/lib/Object/ELFObjectFile.cpp
  llvm/lib/Support/RISCVISAInfo.cpp
  llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
  llvm/lib/Target/RISCV/RISCV.td
  llvm/lib/Target/RISCV/RISCVSubtarget.cpp
  llvm/lib/Target/RISCV/RISCVSubtarget.h
  llvm/test/CodeGen/RISCV/attributes.ll
  llvm/test/MC/RISCV/attribute-arch.s
  llvm/test/tools/llvm-objdump/ELF/RISCV/unknown-arch-attr.test

Index: llvm/test/tools/llvm-objdump/ELF/RISCV/unknown-arch-attr.test
===
--- llvm/test/tools/llvm-objdump/ELF/RISCV/unknown-arch-attr.test
+++ llvm/test/tools/llvm-objdump/ELF/RISCV/unknown-arch-attr.test
@@ -3,7 +3,7 @@
 ## The expected behavior is to ignore the unrecognized arch feature and
 ## continue to process the following arch features.
 ##
-## The object file has the "rv32i2p0_x1p0_m2p0" arch feature. "x1p0" is an
+## The object file has the "rv32i2p0_y1p0_m2p0" arch feature. "y1p0" is an
 ## unrecognized architecture extension. llvm-objdump will ignore it and decode
 ## "mul" instruction correctly according to "m2p0" in the arch feature.
 ##
@@ -34,5 +34,5 @@
 Content: 3385C502
   - Name:.riscv.attributes
 Type:SHT_RISCV_ATTRIBUTES
-## The content is the encoding of the arch feature "rv32i2p0_x1p0_m2p0"
-Content: 4123007269736376000119000572763332693270305F783170305F6D32703000
+## The content is the encoding of the arch feature "rv32i2p0_y1p0_m2p0"
+Content: 4123007269736376000119000572763332693270305F793170305F6D32703000
Index: llvm/test/MC/RISCV/attribute-arch.s
===
--- llvm/test/MC/RISCV/attribute-arch.s
+++ llvm/test/MC/RISCV/attribute-arch.s
@@ -76,3 +76,6 @@
 
 .attribute arch, "rv32iv0p10zvlsseg0p10"
 # CHECK: attribute  5, "rv32i2p0_v0p10_zvlsseg0p10"
+
+.attribute arch, "rv32iv0p7zvlsseg0p7"
+# CHECK: attribute  5, "rv32i2p0_v0p7_zvlsseg0p7"
Index: llvm/test/CodeGen/RISCV/attributes.ll
===
--- llvm/test/CodeGen/RISCV/attributes.ll
+++ llvm/test/CodeGen/RISCV/attributes.ll
@@ -17,6 +17,7 @@
 ; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbr %s -o - | FileCheck --check-prefix=RV32ZBR %s
 ; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbs %s -o - | FileCheck --check-prefix=RV32ZBS %s
 ; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbt %s -o - | FileCheck --check-prefix=RV32ZBT %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-v0p7 %s -o - | FileCheck --check-prefix=RV32V0P7 %s
 ; RUN: llc -mtriple=riscv64 -mattr=+m %s -o - | FileCheck --check-prefix=RV64M %s
 ; RUN: llc -mtriple=riscv64 -mattr=+a %s -o - | FileCheck --check-prefix=RV64A %s
 ; RUN: llc -mtriple=riscv64 -mattr=+f %s -o - | FileCheck --check-prefix=RV64F %s
@@ -34,6 +35,7 @@
 ; RUN: llc -mtriple=riscv64 -mattr=+experimental-zbr %s -o - | FileCheck --check-prefix=RV64ZBR %s
 ; RUN: llc -mtriple=riscv64 -mattr=+experimental-zbs %s -o - | FileCheck --check-prefix=RV64ZBS %s
 ; RUN: llc -mtriple=riscv64 -mattr=+experimental-zbt %s -o - | FileCheck --check-prefix=RV64ZBT %s
+; RUN: llc -mtriple=riscv64 -mattr=+experimental-v0p7 %s -o - | FileCheck --check-prefix=RV64V0P7 %s
 
 ; RV32M: .attribute 5, "rv32i2p0_m2p0"
 ; RV32A: .attribute 5, "rv32i2p0_a2p0"
@@ -53,6 +55,7 @@
 ; RV32ZBR: .attribute 5, "rv32i2p0_zbr0p93"
 ; RV32ZBS: .attribute 5, "rv32i2p0_zbs1p0"
 ; RV32ZBT: .attribute 5, "rv32i2p0_zbt0p93"
+; RV32V0P7: .attribute 5, "rv32i2p0_v0p7_zvlsseg0p7"
 ; RV32COMBINED: .attribute 5, "rv32i2p0_f2p0_v0p10_zfh0p1_zfhmin0p1_zbb1p0_zvlsseg0p10"
 
 ; RV64M: .attribute 5, "rv64i2p0_m2p0"
@@ -73,6 +76,7 @@
 ; RV64ZBS: .attribute 5, "rv64i2p0_zbs1p0"
 ; RV64ZBT: .attribute 5, "rv64i2p0_zbt0p93"
 ; RV64V: .attribute 5, "rv64i2p0_v0p10_zvlsseg0p10"
+; RV64V0P7: .attribute 5, "rv64i2p0_v0p7_zvlsseg0p7"
 ; RV64COMBINED: .attribute 5, "rv64i2p0_f2p0_v0p10_zfh0p1_zfhmin0p1_zbb1p0_zvlsseg0p10"
 
 
Index: llvm/lib/Target/RISCV/RISCVSubtarget.h
===
--- llvm/lib/Target/RISCV/RISCVSubtarget.h
+++ llvm/lib/Target/RISCV/RISCVSubtarget.h
@@ -24,6 +24,7 @@
 #include "llvm/CodeGen/SelectionDAGTargetInfo.h"
 #include "llvm/CodeGen/TargetSubtargetInfo.h"
 #include "llvm/IR/DataLayout.h"
+#include "llvm/Support/RISCVISAInfo.h"
 #include "llvm/Target/TargetMachine.h"
 
 #define GET_SUBTARGETINFO_HEADER
@@ -34,27 +35,28 @@
 
 class RISCVSubtarget : public RISCVGenSubtargetInfo {
   virtual void anchor();
-  bool HasStdExtM = false;
-  bool HasStdExtA = false;
-  bool 

[PATCH] D115921: [RISCV] Refactor the RISCV ISA extension info and target features to support multiple extension version

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu created this revision.
zixuan-wu added reviewers: asb, craig.topper, kito-cheng, luismarques, apazos, 
jrtc27, Jim, akuegel.
Herald added subscribers: VincentWu, luke957, achieveartificialintelligence, 
armkevincheng, eric-k256, vkmr, frasercrmck, jdoerfert, evandro, 
sameer.abuasal, s.egerton, benna, psnobl, jocewei, rupprecht, PkmX, arphaman, 
the_o, brucehoult, MartinMosbeck, rogfer01, edward-jones, zzheng, niosHD, 
sabuasal, simoncook, johnrusso, rbar, hiraditya, emaste, qcolombet, MatzeB.
Herald added a reviewer: jhenderson.
Herald added a reviewer: MaskRay.
Herald added a reviewer: sjarus.
zixuan-wu requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

As RISC-V spec supports multiple extension version, refactor the 
SubtargetFeatures and RISCVISAInfo to support it.

RISCVISAInfo can parse arch string like -march with extension version, but 
related SubtargetFeatures don't contain version info in llvm side. For example, 
SubtargetFeature name is "m" when enable 'm' extension with passing 
`-mattr=+m`. After this patch, it would be `-mattr=+m2p0`.

It also handles arch string with version number of attribute section in obj 
file, including assemble and dis-assemble process.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D115921

Files:
  clang/include/clang/Basic/BuiltinsRISCV.def
  clang/lib/Basic/Targets/RISCV.cpp
  clang/lib/Driver/ToolChains/Arch/RISCV.cpp
  clang/test/CodeGen/RISCV/riscv-attr-builtin-alias-err.c
  clang/test/CodeGen/RISCV/riscv-attr-builtin-alias.c
  clang/test/CodeGen/RISCV/riscv-inline-asm-rvv.c
  clang/test/CodeGen/RISCV/riscv-v-debuginfo.c
  clang/test/CodeGen/RISCV/riscv-v-lifetime.cpp
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbb-error.c
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbb.c
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbc.c
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbe.c
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbp.c
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbr.c
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv64-zbb.c
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv64-zbc.c
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv64-zbe.c
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv64-zbp.c
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv64-zbr.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vaadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vadc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vand.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vasub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vcompress.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vcpop.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vdiv.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfabs.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfclass.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfcvt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfdiv.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfirst.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmax.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmerge.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmin.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmul.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmv.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfncvt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfneg.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfnmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfnmadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfnmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfnmsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfrdiv.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfrec7.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfredmax.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfredmin.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfredsum.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfrsqrt7.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfrsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfsgnj.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfslide1down.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfslide1up.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfsqrt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwadd.c
  

[PATCH] D115923: [RISCV][Don't Commit] Refactor the RISCV ISA extension info and target features to support multiple extension version

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu abandoned this revision.
zixuan-wu added a comment.

Only need review D115921 . Just abandon it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115923

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

[PATCH] D115921: [RISCV] Refactor the RISCV ISA extension info and target features to support multiple extension version

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D115921#3206156 , @jrtc27 wrote:

> Do not bring back V draft 0.7. It is gone, it will never be supported again 
> by LLVM under that name. The standard extension namespace is reserved for 
> ratified extensions and development snapshots only, not old drafts vendors 
> decided to ship. For those, non-standard extension names are needed.

I understood only ratified extension is accepted. Even for ratified extension, 
the version is going to evolve in the future. So this patch is for that. v0p7 
is just used to go through the codepath to support multiple version and test as 
now there is no extension that is not the default version. I will change the 
test way.


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

https://reviews.llvm.org/D115921

___
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] 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] 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.
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] D70401: [WIP][RISCV] Implement ilp32e ABI

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a subscriber: pcwang-thead.
zixuan-wu added a comment.

In D70401#3175266 , @khchen wrote:

>> Is it (D70401 ) good enough to solve or 
>> complete rv32e issue?
>
> It need to
>
> 1. disallow ilp32e ABI with D ISA extension. 
> https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/3f81fae0412bb9ad4002a4ade508be7aa5e1599b/riscv-cc.adoc#ilp32e-calling-convention
> 2. emit predefined marco in header (`__riscv_e`)
> 3. markSuperRegs for X16-X31
> 4. update tests after rebase on main.

Nice. If no body objects, @pcwang-thead will take this task and re-draft a 
review.


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] D108189: [RISCV] Support experimental 'P' extension 0.96

[Zixuan Wu via Phabricator via cfe-commits]

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

Hi, @Jim.
What time is P extension going to upstream to community since it's been no 
update for some months?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108189

___
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] D115921: [RISCV] Refactor the RISCV ISA extension info and target features to support multiple extension version

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D115921#3224284 , @jrtc27 wrote:

> but also with RISC-V extensions not being changed once ratified any more 
> (changes mean new extensions entirely, not new versions)

I don't think so. Or why is there version in RISC-V spec? 
And not only for standard extension, but also it's needed in custom extension.

BTW, it's been supported to parse version of -march in clang side.


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

https://reviews.llvm.org/D115921

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

[PATCH] D115921: [RISCV] Refactor the RISCV ISA extension info and target features to support multiple extension version

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: llvm/lib/Support/RISCVISAInfo.cpp:48
 {"v", RISCVExtensionVersion{0, 10}},
+//{"v", RISCVExtensionVersion{0, 7}},
 {"zba", RISCVExtensionVersion{1, 0}},

jrtc27 wrote:
> Don't do this
This nit will be removed before commit


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

https://reviews.llvm.org/D115921

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

[PATCH] D115921: [RISCV] Refactor the RISCV ISA extension info and target features to support multiple extension version

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

ping...


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

https://reviews.llvm.org/D115921

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

[PATCH] D115921: [RISCV] Refactor the RISCV ISA extension info and target features to support multiple extension version

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D115921#3224329 , @jrtc27 wrote:

> In D115921#3224324 , @zixuan-wu 
> wrote:
>
>> In D115921#3224284 , @jrtc27 wrote:
>>
>>> but also with RISC-V extensions not being changed once ratified any more 
>>> (changes mean new extensions entirely, not new versions)
>>
>> I don't think so. Or why is there version in RISC-V spec?
>
> That was added years ago before there was any plan/policy for ratifying new 
> extensions beyond the initial GC set. 
> https://docs.google.com/presentation/d/1nQ5uFb39KA6gvUi5SReWfIQSiRN7hp6z7ZPfctE4mKk/edit#slide=id.p1
>  is the current lifecycle; note that //only// errata can be fixed after 
> ratification, everything else requires a new extension (see the blue arrow 
> and brown box below it). As far as I can tell, for new extensions it serves 
> no purpose other than to distinguish draft specs from ratified ones.
>
>> And not only for standard extension, but also it's needed in custom 
>> extension.
>
> Vendor extensions are going to be enough of a support pain in Clang. I 
> sincerely hope they don't make life worse by defining multiple versions, 
> rather than doing it properly and defining new extensions every time they add 
> things. It's not just for the toolchain's benefit; it also improves forwards 
> compatibility for kernels/loaders, as they won't know about new versions, but 
> may know about existing versions, so if they support "Xvendorbase" then 
> software that wants to take advantage of "Xvendorbase" and "Xvendornew" can 
> still use "Xvendorbase", but if the kernel/loader only supports "Xvendor1p0" 
> and software wants to use "Xvendor2p0" then it can't do anything, it'd need 
> to be more careful and also have an "Xvendor1p0" implementation. Extending 
> rather than redefining comes with real benefits.
>
>> BTW, it's been supported to parse version of -march in clang side.
>
> It parses and checks the version, but it only allows //the// version of the 
> extension Clang currently implements. Parsing the version is a hard 
> requirement since it can be part of a valid arch string. Supporting multiple 
> versions is not.

If I don't understand wrong, all you want to say is that the extension version 
is just for indication, and not for functionality? So the RV spec does not 
require compiler to support multi-version.

Anybody else has more comments about support multi-version extension? Or it has 
been decided already?


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

https://reviews.llvm.org/D115921

___
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 );
 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 

[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 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 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 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 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 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.

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] 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;  
\

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] 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] 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  : 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  : 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 

[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]

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] 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=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  : 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  : 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__ 

[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 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] 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] 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] 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)

[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 

[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 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 

[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 

[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 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 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] 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 -### 

[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] 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 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] 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] 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] 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] 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 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 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 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] 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