[PATCH] D26858: [AArch64] Don't constrain the assembler when using -mgeneral-regs-only

[James Molloy via cfe-commits]

jmolloy accepted this revision.
jmolloy added a comment.
This revision is now accepted and ready to land.

It's a bit awkward that you need to copy the LastOpt loop from below, but I 
can't see a simpler way to do this.

LGTM.


https://reviews.llvm.org/D26858



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

[PATCH] D26606: Protect tests for std::uninitialized_{copy, fill} under libcpp-no-exceptions

[James Molloy via cfe-commits]

jmolloy added a comment.

Hi,

This looks fairly obviously correct to me, but perhaps someone more familiar 
with libcxx should look too: Asiri?

James


https://reviews.llvm.org/D26606



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

[PATCH] D25761: Use linker flag --fix-cortex-a53-843419 on Android ARM64 compilation.

[James Molloy via cfe-commits]

jmolloy accepted this revision.
jmolloy added a reviewer: jmolloy.
jmolloy added a comment.
This revision is now accepted and ready to land.

LGTM.


https://reviews.llvm.org/D25761



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

[PATCH] D25387: When optimizing for size, enable loop rerolling by default.

[James Molloy via cfe-commits]

jmolloy accepted this revision.
jmolloy added a comment.
This revision is now accepted and ready to land.

Good idea! LGTM!


https://reviews.llvm.org/D25387



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

[PATCH] D25210: [ARM] Add Cortex-R52 target to CLANG

[James Molloy via cfe-commits]

jmolloy added a comment.

Still LGTM.


https://reviews.llvm.org/D25210



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

[PATCH] D25210: [ARM] Add Cortex-R52 target to CLANG

[James Molloy via cfe-commits]

jmolloy accepted this revision.
jmolloy added a comment.
This revision is now accepted and ready to land.

LGTM, thanks Javed!


https://reviews.llvm.org/D25210



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

Re: r280613 - [Modules] Add 'freestanding' to the 'requires-declaration' feature-list.

[James Molloy via cfe-commits]

Hi Elad,

This commit broke all buildbots that don't default to targetting x86. I've
committed a fix with r280658, but could you please double check it's
correct.

Cheers,

James

On Sun, 4 Sep 2016 at 07:09 Elad Cohen via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: eladcohen
> Date: Sun Sep  4 01:00:42 2016
> New Revision: 280613
>
> URL: http://llvm.org/viewvc/llvm-project?rev=280613=rev
> Log:
> [Modules] Add 'freestanding' to the 'requires-declaration' feature-list.
>
> This adds support for modules that require (non-)freestanding
> environment, such as the compiler builtin mm_malloc submodule.
>
> Differential Revision: https://reviews.llvm.org/D23871
>
>
> Added:
> cfe/trunk/test/Modules/compiler_builtins_x86.c
> Modified:
> cfe/trunk/docs/Modules.rst
> cfe/trunk/lib/Basic/Module.cpp
> cfe/trunk/lib/Headers/module.modulemap
>
> Modified: cfe/trunk/docs/Modules.rst
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/Modules.rst?rev=280613=280612=280613=diff
>
> ==
> --- cfe/trunk/docs/Modules.rst (original)
> +++ cfe/trunk/docs/Modules.rst Sun Sep  4 01:00:42 2016
> @@ -413,6 +413,9 @@ cplusplus
>  cplusplus11
>C++11 support is available.
>
> +freestanding
> +  A freestanding environment is available.
> +
>  gnuinlineasm
>GNU inline ASM is available.
>
>
> Modified: cfe/trunk/lib/Basic/Module.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Module.cpp?rev=280613=280612=280613=diff
>
> ==
> --- cfe/trunk/lib/Basic/Module.cpp (original)
> +++ cfe/trunk/lib/Basic/Module.cpp Sun Sep  4 01:00:42 2016
> @@ -64,6 +64,7 @@ static bool hasFeature(StringRef Feature
>  .Case("blocks", LangOpts.Blocks)
>  .Case("cplusplus", LangOpts.CPlusPlus)
>  .Case("cplusplus11", LangOpts.CPlusPlus11)
> +.Case("freestanding", LangOpts.Freestanding)
>  .Case("gnuinlineasm", LangOpts.GNUAsm)
>  .Case("objc", LangOpts.ObjC1)
>  .Case("objc_arc", LangOpts.ObjCAutoRefCount)
>
> Modified: cfe/trunk/lib/Headers/module.modulemap
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/module.modulemap?rev=280613=280612=280613=diff
>
> ==
> --- cfe/trunk/lib/Headers/module.modulemap (original)
> +++ cfe/trunk/lib/Headers/module.modulemap Sun Sep  4 01:00:42 2016
> @@ -63,6 +63,7 @@ module _Builtin_intrinsics [system] [ext
>  textual header "mwaitxintrin.h"
>
>  explicit module mm_malloc {
> +  requires !freestanding
>header "mm_malloc.h"
>export * // note: for  dependency
>  }
>
> Added: cfe/trunk/test/Modules/compiler_builtins_x86.c
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/compiler_builtins_x86.c?rev=280613=auto
>
> ==
> --- cfe/trunk/test/Modules/compiler_builtins_x86.c (added)
> +++ cfe/trunk/test/Modules/compiler_builtins_x86.c Sun Sep  4 01:00:42 2016
> @@ -0,0 +1,6 @@
> +// RUN: rm -rf %t
> +// RUN: %clang_cc1 -fsyntax-only -fmodules -fimplicit-module-maps
> -fmodules-cache-path=%t %s -verify -ffreestanding
> +// expected-no-diagnostics
> +
> +#include
> +
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r280658 - Attempt to fix buildbots not targetting x86

[James Molloy via cfe-commits]

Author: jamesm
Date: Mon Sep  5 07:28:49 2016
New Revision: 280658

URL: http://llvm.org/viewvc/llvm-project?rev=280658=rev
Log:
Attempt to fix buildbots not targetting x86

r280613 introduced failures for all builds that don't target x86 by default. 
Add an explicit target to avoid a missing feature diagnostic.

Modified:
cfe/trunk/test/Modules/compiler_builtins_x86.c

Modified: cfe/trunk/test/Modules/compiler_builtins_x86.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/compiler_builtins_x86.c?rev=280658=280657=280658=diff
==
--- cfe/trunk/test/Modules/compiler_builtins_x86.c (original)
+++ cfe/trunk/test/Modules/compiler_builtins_x86.c Mon Sep  5 07:28:49 2016
@@ -1,5 +1,5 @@
 // RUN: rm -rf %t
-// RUN: %clang_cc1 -fsyntax-only -fmodules -fimplicit-module-maps 
-fmodules-cache-path=%t %s -verify -ffreestanding
+// RUN: %clang_cc1 -triple x86 -fsyntax-only -fmodules -fimplicit-module-maps 
-fmodules-cache-path=%t %s -verify -ffreestanding
 // expected-no-diagnostics
 
 #include


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

r280220 - Attempt to pacify buildbots after r280217

[James Molloy via cfe-commits]

Author: jamesm
Date: Wed Aug 31 06:01:41 2016
New Revision: 280220

URL: http://llvm.org/viewvc/llvm-project?rev=280220=rev
Log:
Attempt to pacify buildbots after r280217

These clang tests check diagnostics from the backend by giving it an 
unvectorizable loop. This loop is now vectorized :/

Make it really unvectorizable by making it unprofitable to ifconvert.

Modified:
cfe/trunk/test/Misc/backend-optimization-failure-nodbg.cpp
cfe/trunk/test/Misc/backend-optimization-failure.cpp

Modified: cfe/trunk/test/Misc/backend-optimization-failure-nodbg.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Misc/backend-optimization-failure-nodbg.cpp?rev=280220=280219=280220=diff
==
--- cfe/trunk/test/Misc/backend-optimization-failure-nodbg.cpp (original)
+++ cfe/trunk/test/Misc/backend-optimization-failure-nodbg.cpp Wed Aug 31 
06:01:41 2016
@@ -4,7 +4,7 @@
 // Test verifies optimization failures generated by the backend are handled
 // correctly by clang. LLVM tests verify all of the failure conditions.
 
-void test_switch(int *A, int *B, int Length) { /* expected-warning {{loop not 
vectorized: failed explicitly specified loop vectorization}} */
+void test_switch(int *A, int *B, int Length, int J) { /* expected-warning 
{{loop not vectorized: failed explicitly specified loop vectorization}} */
 #pragma clang loop vectorize(enable) unroll(disable)
   for (int i = 0; i < Length; i++) {
 switch (A[i]) {
@@ -12,7 +12,7 @@ void test_switch(int *A, int *B, int Len
   B[i] = 1;
   break;
 case 1:
-  B[i] = 2;
+  B[J] = 2;
   break;
 default:
   B[i] = 3;

Modified: cfe/trunk/test/Misc/backend-optimization-failure.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Misc/backend-optimization-failure.cpp?rev=280220=280219=280220=diff
==
--- cfe/trunk/test/Misc/backend-optimization-failure.cpp (original)
+++ cfe/trunk/test/Misc/backend-optimization-failure.cpp Wed Aug 31 06:01:41 
2016
@@ -4,7 +4,7 @@
 // Test verifies optimization failures generated by the backend are handled
 // correctly by clang. LLVM tests verify all of the failure conditions.
 
-void test_switch(int *A, int *B, int Length) {
+void test_switch(int *A, int *B, int Length,int J) {
 #pragma clang loop vectorize(enable) unroll(disable)
   for (int i = 0; i < Length; i++) {
 /* expected-warning@-1 {{loop not vectorized: failed explicitly specified loop 
vectorization}} */ switch (A[i]) {
@@ -12,7 +12,7 @@ void test_switch(int *A, int *B, int Len
   B[i] = 1;
   break;
 case 1:
-  B[i] = 2;
+  B[J] = 2;
   break;
 default:
   B[i] = 3;


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

Re: [PATCH] D23840: New options -fexceptions-fp-math and -fdenormal-fp-math

[James Molloy via cfe-commits]

jmolloy accepted this revision.
jmolloy added a comment.
This revision is now accepted and ready to land.

LGTM.

Cheers,

James


https://reviews.llvm.org/D23840



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

Re: [PATCH] D23840: New options -fexceptions-fp-math and -fdenormal-fp-math

[James Molloy via cfe-commits]

jmolloy added a comment.

Hi Sjoerd,

This still needs a docs patch. I'd also really appreciate someone else to help 
sign this off - While it looks fine, I don't commit enough to clang to give the 
go-ahead.

Cheers,

James


https://reviews.llvm.org/D23840



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

Nomination for 3.9: r278786 - Left shifts of negative values are defined if -fwrapv is set

[James Molloy via cfe-commits]

Hi Hans,

[cc. Richard as code owner]

I'd like to nominate this commit for 3.9. The actual code churn is tiny,
and this fixes a problem noticed by and causing pain to the qemu project.

Cheers,

James

On Tue, 16 Aug 2016 at 10:53 James Molloy via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: jamesm
> Date: Tue Aug 16 04:45:36 2016
> New Revision: 278786
>
> URL: http://llvm.org/viewvc/llvm-project?rev=278786=rev
> Log:
> Left shifts of negative values are defined if -fwrapv is set
>
> This means we shouldn't emit ubsan detection code or warn.
> Fixes PR25552.
>
> Added:
> cfe/trunk/test/CodeGen/wrapv-lshr-sanitize.c
> cfe/trunk/test/Sema/negative-shift-wrapv.c
> Modified:
> cfe/trunk/lib/CodeGen/CGExprScalar.cpp
> cfe/trunk/lib/Sema/SemaExpr.cpp
>
> Modified: cfe/trunk/lib/CodeGen/CGExprScalar.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGExprScalar.cpp?rev=278786=278785=278786=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/CGExprScalar.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGExprScalar.cpp Tue Aug 16 04:45:36 2016
> @@ -2714,7 +2714,8 @@ Value *ScalarExprEmitter::EmitShl(const
>  RHS = Builder.CreateIntCast(RHS, Ops.LHS->getType(), false,
> "sh_prom");
>
>bool SanitizeBase = CGF.SanOpts.has(SanitizerKind::ShiftBase) &&
> -  Ops.Ty->hasSignedIntegerRepresentation();
> +  Ops.Ty->hasSignedIntegerRepresentation() &&
> +  !CGF.getLangOpts().isSignedOverflowDefined();
>bool SanitizeExponent = CGF.SanOpts.has(SanitizerKind::ShiftExponent);
>// OpenCL 6.3j: shift values are effectively % word size of LHS.
>if (CGF.getLangOpts().OpenCL)
>
> Modified: cfe/trunk/lib/Sema/SemaExpr.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExpr.cpp?rev=278786=278785=278786=diff
>
> ==
> --- cfe/trunk/lib/Sema/SemaExpr.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaExpr.cpp Tue Aug 16 04:45:36 2016
> @@ -8670,7 +8670,7 @@ static void DiagnoseBadShiftValues(Sema&
>
>// If LHS does not have a signed type and non-negative value
>// then, the behavior is undefined. Warn about it.
> -  if (Left.isNegative()) {
> +  if (Left.isNegative() && !S.getLangOpts().isSignedOverflowDefined()) {
>  S.DiagRuntimeBehavior(Loc, LHS.get(),
>S.PDiag(diag::warn_shift_lhs_negative)
>  << LHS.get()->getSourceRange());
>
> Added: cfe/trunk/test/CodeGen/wrapv-lshr-sanitize.c
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/wrapv-lshr-sanitize.c?rev=278786=auto
>
> ==
> --- cfe/trunk/test/CodeGen/wrapv-lshr-sanitize.c (added)
> +++ cfe/trunk/test/CodeGen/wrapv-lshr-sanitize.c Tue Aug 16 04:45:36 2016
> @@ -0,0 +1,12 @@
> +// RUN: %clang_cc1 -fsanitize=shift-base -emit-llvm %s -o - -triple
> x86_64-linux-gnu -fwrapv | FileCheck %s
> +
> +// CHECK-LABEL: @lsh_overflow
> +int lsh_overflow(int a, int b) {
> +  // CHECK-NOT: br
> +  // CHECK-NOT: call void @__ubsan_
> +  // CHECK-NOT: call void @llvm.trap
> +
> +  // CHECK:  %[[RET:.*]] = shl i32
> +  // CHECK-NEXT: ret i32 %[[RET]]
> +  return a << b;
> +}
>
> Added: cfe/trunk/test/Sema/negative-shift-wrapv.c
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/negative-shift-wrapv.c?rev=278786=auto
>
> ==
> --- cfe/trunk/test/Sema/negative-shift-wrapv.c (added)
> +++ cfe/trunk/test/Sema/negative-shift-wrapv.c Tue Aug 16 04:45:36 2016
> @@ -0,0 +1,9 @@
> +// RUN: %clang_cc1 -Wall -ffreestanding -fsyntax-only -fwrapv -verify %s
> +
> +int test() {
> +  int i;
> +  i = -1 << 1; // no-warning
> +  return i;
> +}
> +
> +// expected-no-diagnostics
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D23498: Left shifts of negative values are defined if -fwrapv is set

[James Molloy via cfe-commits]

jmolloy accepted this revision.
jmolloy added a reviewer: jmolloy.
jmolloy added a comment.
This revision is now accepted and ready to land.

Thanks, r278786!


https://reviews.llvm.org/D23498



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

r278786 - Left shifts of negative values are defined if -fwrapv is set

[James Molloy via cfe-commits]

Author: jamesm
Date: Tue Aug 16 04:45:36 2016
New Revision: 278786

URL: http://llvm.org/viewvc/llvm-project?rev=278786=rev
Log:
Left shifts of negative values are defined if -fwrapv is set

This means we shouldn't emit ubsan detection code or warn.
Fixes PR25552.

Added:
cfe/trunk/test/CodeGen/wrapv-lshr-sanitize.c
cfe/trunk/test/Sema/negative-shift-wrapv.c
Modified:
cfe/trunk/lib/CodeGen/CGExprScalar.cpp
cfe/trunk/lib/Sema/SemaExpr.cpp

Modified: cfe/trunk/lib/CodeGen/CGExprScalar.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGExprScalar.cpp?rev=278786=278785=278786=diff
==
--- cfe/trunk/lib/CodeGen/CGExprScalar.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGExprScalar.cpp Tue Aug 16 04:45:36 2016
@@ -2714,7 +2714,8 @@ Value *ScalarExprEmitter::EmitShl(const
 RHS = Builder.CreateIntCast(RHS, Ops.LHS->getType(), false, "sh_prom");
 
   bool SanitizeBase = CGF.SanOpts.has(SanitizerKind::ShiftBase) &&
-  Ops.Ty->hasSignedIntegerRepresentation();
+  Ops.Ty->hasSignedIntegerRepresentation() &&
+  !CGF.getLangOpts().isSignedOverflowDefined();
   bool SanitizeExponent = CGF.SanOpts.has(SanitizerKind::ShiftExponent);
   // OpenCL 6.3j: shift values are effectively % word size of LHS.
   if (CGF.getLangOpts().OpenCL)

Modified: cfe/trunk/lib/Sema/SemaExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExpr.cpp?rev=278786=278785=278786=diff
==
--- cfe/trunk/lib/Sema/SemaExpr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExpr.cpp Tue Aug 16 04:45:36 2016
@@ -8670,7 +8670,7 @@ static void DiagnoseBadShiftValues(Sema&
 
   // If LHS does not have a signed type and non-negative value
   // then, the behavior is undefined. Warn about it.
-  if (Left.isNegative()) {
+  if (Left.isNegative() && !S.getLangOpts().isSignedOverflowDefined()) {
 S.DiagRuntimeBehavior(Loc, LHS.get(),
   S.PDiag(diag::warn_shift_lhs_negative)
 << LHS.get()->getSourceRange());

Added: cfe/trunk/test/CodeGen/wrapv-lshr-sanitize.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/wrapv-lshr-sanitize.c?rev=278786=auto
==
--- cfe/trunk/test/CodeGen/wrapv-lshr-sanitize.c (added)
+++ cfe/trunk/test/CodeGen/wrapv-lshr-sanitize.c Tue Aug 16 04:45:36 2016
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -fsanitize=shift-base -emit-llvm %s -o - -triple 
x86_64-linux-gnu -fwrapv | FileCheck %s
+
+// CHECK-LABEL: @lsh_overflow
+int lsh_overflow(int a, int b) {
+  // CHECK-NOT: br
+  // CHECK-NOT: call void @__ubsan_
+  // CHECK-NOT: call void @llvm.trap
+  
+  // CHECK:  %[[RET:.*]] = shl i32
+  // CHECK-NEXT: ret i32 %[[RET]]
+  return a << b;
+}

Added: cfe/trunk/test/Sema/negative-shift-wrapv.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/negative-shift-wrapv.c?rev=278786=auto
==
--- cfe/trunk/test/Sema/negative-shift-wrapv.c (added)
+++ cfe/trunk/test/Sema/negative-shift-wrapv.c Tue Aug 16 04:45:36 2016
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -Wall -ffreestanding -fsyntax-only -fwrapv -verify %s
+
+int test() {
+  int i;
+  i = -1 << 1; // no-warning
+  return i;
+}
+
+// expected-no-diagnostics


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

Re: [PATCH] D23498: Left shifts of negative values are defined if -fwrapv is set

[James Molloy via cfe-commits]

jmolloy added a comment.

Hi Filipe,

Did this look good to you after those changes?

Cheers,

James


https://reviews.llvm.org/D23498



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

Re: [PATCH] D23498: Left shifts of negative values are defined if -fwrapv is set

[James Molloy via cfe-commits]

jmolloy updated this revision to Diff 68033.
jmolloy added a comment.

Hi Filipe,

Thanks for the review! SGTM on both counts.


https://reviews.llvm.org/D23498

Files:
  lib/CodeGen/CGExprScalar.cpp
  lib/Sema/SemaExpr.cpp
  test/CodeGen/wrapv-lshr-sanitize.c
  test/Sema/negative-shift-wrapv.c

Index: test/Sema/negative-shift-wrapv.c
===
--- /dev/null
+++ test/Sema/negative-shift-wrapv.c
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -Wall -ffreestanding -fsyntax-only -fwrapv -verify %s
+
+int test() {
+  int i;
+  i = -1 << 1; // no-warning
+  return i;
+}
+
+// expected-no-diagnostics
Index: test/CodeGen/wrapv-lshr-sanitize.c
===
--- /dev/null
+++ test/CodeGen/wrapv-lshr-sanitize.c
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -fsanitize=shift-base -emit-llvm %s -o - -triple 
x86_64-linux-gnu -fwrapv | FileCheck %s
+
+// CHECK-LABEL: @lsh_overflow
+int lsh_overflow(int a, int b) {
+  // CHECK-NOT: br
+  // CHECK-NOT: call void @__ubsan_
+  // CHECK-NOT: call void @llvm.trap
+  
+  // CHECK:  %[[RET:.*]] = shl i32
+  // CHECK-NEXT: ret i32 %[[RET]]
+  return a << b;
+}
Index: lib/Sema/SemaExpr.cpp
===
--- lib/Sema/SemaExpr.cpp
+++ lib/Sema/SemaExpr.cpp
@@ -8567,7 +8567,7 @@
 
   // If LHS does not have a signed type and non-negative value
   // then, the behavior is undefined. Warn about it.
-  if (Left.isNegative()) {
+  if (Left.isNegative() && !S.getLangOpts().isSignedOverflowDefined()) {
 S.DiagRuntimeBehavior(Loc, LHS.get(),
   S.PDiag(diag::warn_shift_lhs_negative)
 << LHS.get()->getSourceRange());
Index: lib/CodeGen/CGExprScalar.cpp
===
--- lib/CodeGen/CGExprScalar.cpp
+++ lib/CodeGen/CGExprScalar.cpp
@@ -2706,7 +2706,8 @@
 RHS = Builder.CreateIntCast(RHS, Ops.LHS->getType(), false, "sh_prom");
 
   bool SanitizeBase = CGF.SanOpts.has(SanitizerKind::ShiftBase) &&
-  Ops.Ty->hasSignedIntegerRepresentation();
+  Ops.Ty->hasSignedIntegerRepresentation() &&
+  !CGF.getLangOpts().isSignedOverflowDefined();
   bool SanitizeExponent = CGF.SanOpts.has(SanitizerKind::ShiftExponent);
   // OpenCL 6.3j: shift values are effectively % word size of LHS.
   if (CGF.getLangOpts().OpenCL)


Index: test/Sema/negative-shift-wrapv.c
===
--- /dev/null
+++ test/Sema/negative-shift-wrapv.c
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -Wall -ffreestanding -fsyntax-only -fwrapv -verify %s
+
+int test() {
+  int i;
+  i = -1 << 1; // no-warning
+  return i;
+}
+
+// expected-no-diagnostics
Index: test/CodeGen/wrapv-lshr-sanitize.c
===
--- /dev/null
+++ test/CodeGen/wrapv-lshr-sanitize.c
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -fsanitize=shift-base -emit-llvm %s -o - -triple x86_64-linux-gnu -fwrapv | FileCheck %s
+
+// CHECK-LABEL: @lsh_overflow
+int lsh_overflow(int a, int b) {
+  // CHECK-NOT: br
+  // CHECK-NOT: call void @__ubsan_
+  // CHECK-NOT: call void @llvm.trap
+  
+  // CHECK:  %[[RET:.*]] = shl i32
+  // CHECK-NEXT: ret i32 %[[RET]]
+  return a << b;
+}
Index: lib/Sema/SemaExpr.cpp
===
--- lib/Sema/SemaExpr.cpp
+++ lib/Sema/SemaExpr.cpp
@@ -8567,7 +8567,7 @@
 
   // If LHS does not have a signed type and non-negative value
   // then, the behavior is undefined. Warn about it.
-  if (Left.isNegative()) {
+  if (Left.isNegative() && !S.getLangOpts().isSignedOverflowDefined()) {
 S.DiagRuntimeBehavior(Loc, LHS.get(),
   S.PDiag(diag::warn_shift_lhs_negative)
 << LHS.get()->getSourceRange());
Index: lib/CodeGen/CGExprScalar.cpp
===
--- lib/CodeGen/CGExprScalar.cpp
+++ lib/CodeGen/CGExprScalar.cpp
@@ -2706,7 +2706,8 @@
 RHS = Builder.CreateIntCast(RHS, Ops.LHS->getType(), false, "sh_prom");
 
   bool SanitizeBase = CGF.SanOpts.has(SanitizerKind::ShiftBase) &&
-  Ops.Ty->hasSignedIntegerRepresentation();
+  Ops.Ty->hasSignedIntegerRepresentation() &&
+  !CGF.getLangOpts().isSignedOverflowDefined();
   bool SanitizeExponent = CGF.SanOpts.has(SanitizerKind::ShiftExponent);
   // OpenCL 6.3j: shift values are effectively % word size of LHS.
   if (CGF.getLangOpts().OpenCL)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D23498: Left shifts of negative values are defined if -fwrapv is set

[James Molloy via cfe-commits]

jmolloy created this revision.
jmolloy added reviewers: davide, aaron.ballman.
jmolloy added a subscriber: cfe-commits.

This means we shouldn't emit ubsan detection code or warn.
Fixes PR25552.

https://reviews.llvm.org/D23498

Files:
  lib/CodeGen/CGExprScalar.cpp
  lib/Sema/SemaExpr.cpp
  test/CodeGen/wrapv-lshr-sanitize.c
  test/Sema/negative-shift-wrapv.c

Index: test/Sema/negative-shift-wrapv.c
===
--- /dev/null
+++ test/Sema/negative-shift-wrapv.c
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -Wall -ffreestanding -fsyntax-only -fwrapv -verify %s
+
+#include 
+
+#define WORD_BIT (sizeof(int) * CHAR_BIT)
+
+void test() {
+  int i;
+  i = -1 << (WORD_BIT - 1); // no-warning
+}
+
+// expected-no-diagnostics
Index: test/CodeGen/wrapv-lshr-sanitize.c
===
--- /dev/null
+++ test/CodeGen/wrapv-lshr-sanitize.c
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -fsanitize=shift-base -emit-llvm %s -o - -triple 
x86_64-linux-gnu -fwrapv | opt -instnamer -S | FileCheck %s
+
+// CHECK-LABEL: @lsh_overflow
+int lsh_overflow(int a, int b) {
+  // CHECK-NOT: br
+  // CHECK-NOT: call void @__ubsan_
+  // CHECK-NOT: call void @llvm.trap
+  
+  // CHECK:  %[[RET:.*]] = shl i32
+  // CHECK-NEXT: ret i32 %[[RET]]
+  return a << b;
+}
Index: lib/Sema/SemaExpr.cpp
===
--- lib/Sema/SemaExpr.cpp
+++ lib/Sema/SemaExpr.cpp
@@ -8567,7 +8567,7 @@
 
   // If LHS does not have a signed type and non-negative value
   // then, the behavior is undefined. Warn about it.
-  if (Left.isNegative()) {
+  if (Left.isNegative() && !S.getLangOpts().isSignedOverflowDefined()) {
 S.DiagRuntimeBehavior(Loc, LHS.get(),
   S.PDiag(diag::warn_shift_lhs_negative)
 << LHS.get()->getSourceRange());
Index: lib/CodeGen/CGExprScalar.cpp
===
--- lib/CodeGen/CGExprScalar.cpp
+++ lib/CodeGen/CGExprScalar.cpp
@@ -2706,7 +2706,8 @@
 RHS = Builder.CreateIntCast(RHS, Ops.LHS->getType(), false, "sh_prom");
 
   bool SanitizeBase = CGF.SanOpts.has(SanitizerKind::ShiftBase) &&
-  Ops.Ty->hasSignedIntegerRepresentation();
+  Ops.Ty->hasSignedIntegerRepresentation() &&
+  !CGF.getLangOpts().isSignedOverflowDefined();
   bool SanitizeExponent = CGF.SanOpts.has(SanitizerKind::ShiftExponent);
   // OpenCL 6.3j: shift values are effectively % word size of LHS.
   if (CGF.getLangOpts().OpenCL)


Index: test/Sema/negative-shift-wrapv.c
===
--- /dev/null
+++ test/Sema/negative-shift-wrapv.c
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -Wall -ffreestanding -fsyntax-only -fwrapv -verify %s
+
+#include 
+
+#define WORD_BIT (sizeof(int) * CHAR_BIT)
+
+void test() {
+  int i;
+  i = -1 << (WORD_BIT - 1); // no-warning
+}
+
+// expected-no-diagnostics
Index: test/CodeGen/wrapv-lshr-sanitize.c
===
--- /dev/null
+++ test/CodeGen/wrapv-lshr-sanitize.c
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -fsanitize=shift-base -emit-llvm %s -o - -triple x86_64-linux-gnu -fwrapv | opt -instnamer -S | FileCheck %s
+
+// CHECK-LABEL: @lsh_overflow
+int lsh_overflow(int a, int b) {
+  // CHECK-NOT: br
+  // CHECK-NOT: call void @__ubsan_
+  // CHECK-NOT: call void @llvm.trap
+  
+  // CHECK:  %[[RET:.*]] = shl i32
+  // CHECK-NEXT: ret i32 %[[RET]]
+  return a << b;
+}
Index: lib/Sema/SemaExpr.cpp
===
--- lib/Sema/SemaExpr.cpp
+++ lib/Sema/SemaExpr.cpp
@@ -8567,7 +8567,7 @@
 
   // If LHS does not have a signed type and non-negative value
   // then, the behavior is undefined. Warn about it.
-  if (Left.isNegative()) {
+  if (Left.isNegative() && !S.getLangOpts().isSignedOverflowDefined()) {
 S.DiagRuntimeBehavior(Loc, LHS.get(),
   S.PDiag(diag::warn_shift_lhs_negative)
 << LHS.get()->getSourceRange());
Index: lib/CodeGen/CGExprScalar.cpp
===
--- lib/CodeGen/CGExprScalar.cpp
+++ lib/CodeGen/CGExprScalar.cpp
@@ -2706,7 +2706,8 @@
 RHS = Builder.CreateIntCast(RHS, Ops.LHS->getType(), false, "sh_prom");
 
   bool SanitizeBase = CGF.SanOpts.has(SanitizerKind::ShiftBase) &&
-  Ops.Ty->hasSignedIntegerRepresentation();
+  Ops.Ty->hasSignedIntegerRepresentation() &&
+  !CGF.getLangOpts().isSignedOverflowDefined();
   bool SanitizeExponent = CGF.SanOpts.has(SanitizerKind::ShiftExponent);
   // OpenCL 6.3j: shift values are effectively % word size of LHS.
   if (CGF.getLangOpts().OpenCL)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org

Re: [PATCH] D21295: Add a negative TBAA test

[James Molloy via cfe-commits]

jmolloy added a comment.

Private reply:

fine by me but a clang person needs to a accept it.


http://reviews.llvm.org/D21295



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

Re: [PATCH] D21295: Add a negative TBAA test

[James Molloy via cfe-commits]

jmolloy added a subscriber: jmolloy.


Comment at: test/CodeGen/tbaa.cpp:57
@@ +56,3 @@
+// NO-TBAA-LABEL: define i32 @_Z1g
+// NO-TBAA: store i32 1, i32* %{{.*}}, align 4{{ *$}}
+// NO-TBAA: store i32 4, i32* %{{.*}}, align 4{{ *$}}

Would it just be simpler to do:

// NO-TBAA-NOT: !tbaa

at the top of the file?


http://reviews.llvm.org/D21295



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

Re: [PATCH] D20089: Adding a TargetParser for AArch64

[James Molloy via cfe-commits]

jmolloy added a comment.

As far as I'm concerned, if you're happy I'm happy. You know this area more 
than me.


Repository:
  rL LLVM

http://reviews.llvm.org/D20089



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

Re: [PATCH] D20325: Add ARM cdp intrinsics

[James Molloy via cfe-commits]

Hi,

To add my oar in, I agree with Tim here. It is regrettable but true that
documentation, be that the ARMARM or ACLE tends to lag behind our
development. If LLVM wants to be at the leading edge of architecture
support (I hope it does!) then patches will just have to be accepted
without pointers to existing documentation, because the documentation is
still in draft. It's either that or wait until the documentation is ready,
which can be quite some time (there is no v8.1A ARMARM yet...)

The ACLE in particular stays in draft for some time, because it often waits
for implementations to be done in GCC and LLVM to see if the specification
is actually workable!

Cheers,

James

On Wed, 18 May 2016 at 11:03 Renato Golin via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> rengolin added a comment.
>
> Thanks Ranjeet,
>
> The tests don't really need the new builtin to exist at all and can be
> added now.
>
> When you submit the __arm_cdp patch, you just need to make sure Clang
> generates a call to @llvm.arm.cdp and everything else will be covered.
>
> cheers,
> --renato
>
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D20325
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D16929: add support for -print-imm-hex for AArch64

[James Molloy via cfe-commits]

jmolloy accepted this revision.
jmolloy added a comment.
This revision is now accepted and ready to land.

LGTM, thanks!


Repository:
  rL LLVM

http://reviews.llvm.org/D16929



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

Re: [PATCH] D16929: add support for -print-imm-hex for AArch64

[James Molloy via cfe-commits]

jmolloy added a comment.

Hi Pawel,

Thanks for this - it generally looks good to me. Just one comment.

James



Comment at: lib/Target/AArch64/InstPrinter/AArch64InstPrinter.h:107
@@ -106,3 @@
-  template 
-  void printAMIndexedWB(const MCInst *MI, unsigned OpNum,
-const MCSubtargetInfo , raw_ostream ) {

Is this dead code you're deleting?


Repository:
  rL LLVM

http://reviews.llvm.org/D16929



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

Re: [PATCH] D16056: [Gold] Pass -mllvm options to the gold plugin

[James Molloy via cfe-commits]

jmolloy abandoned this revision.
jmolloy added a comment.

Abandoning - this isn't as clear-cut as I thought.


Repository:
  rL LLVM

http://reviews.llvm.org/D16056



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

Re: [PATCH] D16056: [Gold] Pass -mllvm options to the gold plugin

[James Molloy via cfe-commits]

Ok, I'll abandon this.

It wasn't meant to be contentious and this is a reasonable objection!

James



> On 12 Jan 2016, at 00:53, Mehdi Amini  wrote:
>
> I’d fear the same thing. On our platform you have to use explicitly 
> -Wl,-mllvm  (or -Xlinker -plugin-opt).
>
> —
> Mehdi
>
>
>> On Jan 11, 2016, at 4:11 PM, Rafael Espíndola  
>> wrote:
>>
>> Maybe. I would like a second opinion on this one. The potential issue
>> I see is that we are using compiler options during linking. Normally
>> they are just ignored. Is it surprising if LTO starts using them?
>>
>> Cheers,
>> Rafael
>>
>>
>>> On 11 January 2016 at 06:47, James Molloy  wrote:
>>> jmolloy created this revision.
>>> jmolloy added a reviewer: rafael.
>>> jmolloy added a subscriber: cfe-commits.
>>> jmolloy set the repository for this revision to rL LLVM.
>>> Herald added a subscriber: joker.eph.
>>>
>>> The gold plugin can take LLVM options, but the syntax is confusing: 
>>> -Wl,-plugin-opt= or -Xlinker -plugin-opt=.
>>>
>>> Instead, pass -mllvm options through to Gold so the obvious syntax works.
>>>
>>> Repository:
>>> rL LLVM
>>>
>>> http://reviews.llvm.org/D16056
>>>
>>> Files:
>>> lib/Driver/Tools.cpp
>>> test/Driver/gold-lto.c
>>>
>>> Index: test/Driver/gold-lto.c
>>> ===
>>> --- test/Driver/gold-lto.c
>>> +++ test/Driver/gold-lto.c
>>> @@ -16,11 +16,14 @@
>>> // CHECK-X86-64-COREI7: "-plugin-opt=foo"
>>> //
>>> // RUN: %clang -target arm-unknown-linux -### %t.o -flto 2>&1 \
>>> -// RUN: -march=armv7a -Wl,-plugin-opt=foo -O0 \
>>> +// RUN: -march=armv7a -Wl,-plugin-opt=foo -O0 -mllvm -bar=baz \
>>> +// RUN: -mllvm -test-option \
>>> // RUN: | FileCheck %s --check-prefix=CHECK-ARM-V7A
>>> // CHECK-ARM-V7A: "-plugin" "{{.*}}/LLVMgold.so"
>>> // CHECK-ARM-V7A: "-plugin-opt=mcpu=cortex-a8"
>>> // CHECK-ARM-V7A: "-plugin-opt=O0"
>>> +// CHECK-ARM-V7A: "-plugin-opt=-bar=baz"
>>> +// CHECK-ARM-V7A: "-plugin-opt=-test-option"
>>> // CHECK-ARM-V7A: "-plugin-opt=foo"
>>> //
>>> // RUN: %clang -target i686-linux-android -### %t.o -flto 2>&1 \
>>> Index: lib/Driver/Tools.cpp
>>> ===
>>> --- lib/Driver/Tools.cpp
>>> +++ lib/Driver/Tools.cpp
>>> @@ -1817,6 +1817,12 @@
>>>
>>>  if (IsThinLTO)
>>>CmdArgs.push_back("-plugin-opt=thinlto");
>>> +
>>> +  // Claim and pass through -mllvm options to the Gold plugin.
>>> +  for (const Arg *A : Args.filtered(options::OPT_mllvm)) {
>>> +A->claim();
>>> +CmdArgs.push_back(Args.MakeArgString(Twine("-plugin-opt=") + 
>>> A->getValue(0)));
>>> +  }
>>> }
>>>
>>> /// This is a helper function for validating the optional refinement step
>
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

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

Re: [PATCH] D15641: [Driver] Pass -O* to the gold plugin via -plugin-opt

[James Molloy via cfe-commits]

jmolloy accepted this revision.
jmolloy added a reviewer: jmolloy.
jmolloy added a comment.
This revision is now accepted and ready to land.

Hi,

As we got to the bottom of why this is actually needed, I committed this with 
the changes suggested by Rafael in r256146.

Cheers,

James


Repository:
  rL LLVM

http://reviews.llvm.org/D15641



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

r256146 - [Driver] Pass -O* to the gold plugin via -plugin-opt

[James Molloy via cfe-commits]

Author: jamesm
Date: Mon Dec 21 04:44:36 2015
New Revision: 256146

URL: http://llvm.org/viewvc/llvm-project?rev=256146=rev
Log:
[Driver] Pass -O* to the gold plugin via -plugin-opt

The gold plugin understands -O0..-O3, but these are not currently being passed 
to it.

Modified:
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/test/Driver/gold-lto.c

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=256146=256145=256146=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Mon Dec 21 04:44:36 2015
@@ -1796,6 +1796,19 @@ static void AddGoldPlugin(const ToolChai
   if (!CPU.empty())
 CmdArgs.push_back(Args.MakeArgString(Twine("-plugin-opt=mcpu=") + CPU));
 
+  if (Arg *A = Args.getLastArg(options::OPT_O_Group)) {
+StringRef OOpt;
+if (A->getOption().matches(options::OPT_O4) ||
+A->getOption().matches(options::OPT_Ofast))
+  OOpt = "3";
+else if (A->getOption().matches(options::OPT_O))
+  OOpt = A->getValue();
+else if (A->getOption().matches(options::OPT_O0))
+  OOpt = "0";
+if (!OOpt.empty())
+  CmdArgs.push_back(Args.MakeArgString(Twine("-plugin-opt=O") + OOpt));
+  }
+
   if (IsThinLTO)
 CmdArgs.push_back("-plugin-opt=thinlto");
 }

Modified: cfe/trunk/test/Driver/gold-lto.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/gold-lto.c?rev=256146=256145=256146=diff
==
--- cfe/trunk/test/Driver/gold-lto.c (original)
+++ cfe/trunk/test/Driver/gold-lto.c Mon Dec 21 04:44:36 2015
@@ -1,23 +1,26 @@
 // RUN: touch %t.o
 //
 // RUN: %clang -target x86_64-unknown-linux -### %t.o -flto 2>&1 \
-// RUN: -Wl,-plugin-opt=foo \
+// RUN: -Wl,-plugin-opt=foo -O3 \
 // RUN: | FileCheck %s --check-prefix=CHECK-X86-64-BASIC
 // CHECK-X86-64-BASIC: "-plugin" "{{.*}}/LLVMgold.so"
+// CHECK-X86-64-BASIC: "-plugin-opt=O3"
 // CHECK-X86-64-BASIC: "-plugin-opt=foo"
 //
 // RUN: %clang -target x86_64-unknown-linux -### %t.o -flto 2>&1 \
-// RUN: -march=corei7 -Wl,-plugin-opt=foo \
+// RUN: -march=corei7 -Wl,-plugin-opt=foo -Ofast \
 // RUN: | FileCheck %s --check-prefix=CHECK-X86-64-COREI7
 // CHECK-X86-64-COREI7: "-plugin" "{{.*}}/LLVMgold.so"
 // CHECK-X86-64-COREI7: "-plugin-opt=mcpu=corei7"
+// CHECK-X86-64-COREI7: "-plugin-opt=O3"
 // CHECK-X86-64-COREI7: "-plugin-opt=foo"
 //
 // RUN: %clang -target arm-unknown-linux -### %t.o -flto 2>&1 \
-// RUN: -march=armv7a -Wl,-plugin-opt=foo \
+// RUN: -march=armv7a -Wl,-plugin-opt=foo -O0 \
 // RUN: | FileCheck %s --check-prefix=CHECK-ARM-V7A
 // CHECK-ARM-V7A: "-plugin" "{{.*}}/LLVMgold.so"
 // CHECK-ARM-V7A: "-plugin-opt=mcpu=cortex-a8"
+// CHECK-ARM-V7A: "-plugin-opt=O0"
 // CHECK-ARM-V7A: "-plugin-opt=foo"
 //
 // RUN: %clang -target i686-linux-android -### %t.o -flto 2>&1 \


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

Re: [PATCH] D15641: [Driver] Pass -O* to the gold plugin via -plugin-opt

[James Molloy via cfe-commits]

It's interesting to think about, but not something I'm intending to attack
right now.

I mainly just wanted to know the answer to Joerg's question, and now I do :)

James
On Sat, 19 Dec 2015 at 17:17, Mehdi Amini via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
>
> Sent from my iPhone
>
> > On Dec 18, 2015, at 11:11 PM, James Molloy  wrote:
> >
> > Hi Mehdi,
> >
> >> On 18 Dec 2015, at 23:17, Mehdi Amini  wrote:
> >>
> >> The alternative to the command line flag is to encode the optimization
> level in the bitcode itself.
> >
> > You may have answered Joerg's question here - I take it this is not yet
> implemented?
>
> Not implemented. We have settled on the various tradeoff. Are you
> interested to think about this?
> --
> Mehdi
> >
> > James
> > IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> >
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D15641: [Driver] Pass -O* to the gold plugin via -plugin-opt

[James Molloy via cfe-commits]

Hi Mehdi,

> On 18 Dec 2015, at 23:17, Mehdi Amini  wrote:
>
> The alternative to the command line flag is to encode the optimization level 
> in the bitcode itself.

You may have answered Joerg's question here - I take it this is not yet 
implemented?

James
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

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

[PATCH] D15641: [Driver] Pass -O* to the gold plugin via -plugin-opt

[James Molloy via cfe-commits]

jmolloy created this revision.
jmolloy added a reviewer: joerg.
jmolloy added a subscriber: cfe-commits.
jmolloy set the repository for this revision to rL LLVM.
Herald added a subscriber: joker.eph.

The gold plugin understands -O0..-O3, but these are not currently being passed 
to it.

Repository:
  rL LLVM

http://reviews.llvm.org/D15641

Files:
  lib/Driver/Tools.cpp
  test/Driver/gold-lto.c

Index: test/Driver/gold-lto.c
===
--- test/Driver/gold-lto.c
+++ test/Driver/gold-lto.c
@@ -1,23 +1,26 @@
 // RUN: touch %t.o
 //
 // RUN: %clang -target x86_64-unknown-linux -### %t.o -flto 2>&1 \
-// RUN: -Wl,-plugin-opt=foo \
+// RUN: -Wl,-plugin-opt=foo -O3 \
 // RUN: | FileCheck %s --check-prefix=CHECK-X86-64-BASIC
 // CHECK-X86-64-BASIC: "-plugin" "{{.*}}/LLVMgold.so"
+// CHECK-X86-64-BASIC: "-plugin-opt=O3"
 // CHECK-X86-64-BASIC: "-plugin-opt=foo"
 //
 // RUN: %clang -target x86_64-unknown-linux -### %t.o -flto 2>&1 \
-// RUN: -march=corei7 -Wl,-plugin-opt=foo \
+// RUN: -march=corei7 -Wl,-plugin-opt=foo -Ofast \
 // RUN: | FileCheck %s --check-prefix=CHECK-X86-64-COREI7
 // CHECK-X86-64-COREI7: "-plugin" "{{.*}}/LLVMgold.so"
 // CHECK-X86-64-COREI7: "-plugin-opt=mcpu=corei7"
+// CHECK-X86-64-COREI7: "-plugin-opt=O3"
 // CHECK-X86-64-COREI7: "-plugin-opt=foo"
 //
 // RUN: %clang -target arm-unknown-linux -### %t.o -flto 2>&1 \
-// RUN: -march=armv7a -Wl,-plugin-opt=foo \
+// RUN: -march=armv7a -Wl,-plugin-opt=foo -O0 \
 // RUN: | FileCheck %s --check-prefix=CHECK-ARM-V7A
 // CHECK-ARM-V7A: "-plugin" "{{.*}}/LLVMgold.so"
 // CHECK-ARM-V7A: "-plugin-opt=mcpu=cortex-a8"
+// CHECK-ARM-V7A: "-plugin-opt=O0"
 // CHECK-ARM-V7A: "-plugin-opt=foo"
 //
 // RUN: %clang -target i686-linux-android -### %t.o -flto 2>&1 \
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -1804,6 +1804,21 @@
   if (!CPU.empty())
 CmdArgs.push_back(Args.MakeArgString(Twine("-plugin-opt=mcpu=") + CPU));
 
+  if (Arg *A = Args.getLastArg(options::OPT_O_Group)) {
+if (A->getOption().matches(options::OPT_O4) ||
+A->getOption().matches(options::OPT_Ofast)) {
+  CmdArgs.push_back("-plugin-opt=O3");
+} else if (A->getOption().matches(options::OPT_O)) {
+  CmdArgs.push_back(
+  Args.MakeArgString(Twine("-plugin-opt=O") + A->getValue()));
+} else if (A->getOption().matches(options::OPT_O0)) {
+  CmdArgs.push_back("-plugin-opt=O0");
+} else {
+  ToolChain.getDriver().Diag(clang::diag::warn_drv_unused_argument)
+  << A->getAsString(Args);
+}
+  }
+
   if (IsThinLTO)
 CmdArgs.push_back("-plugin-opt=thinlto");
 }


Index: test/Driver/gold-lto.c
===
--- test/Driver/gold-lto.c
+++ test/Driver/gold-lto.c
@@ -1,23 +1,26 @@
 // RUN: touch %t.o
 //
 // RUN: %clang -target x86_64-unknown-linux -### %t.o -flto 2>&1 \
-// RUN: -Wl,-plugin-opt=foo \
+// RUN: -Wl,-plugin-opt=foo -O3 \
 // RUN: | FileCheck %s --check-prefix=CHECK-X86-64-BASIC
 // CHECK-X86-64-BASIC: "-plugin" "{{.*}}/LLVMgold.so"
+// CHECK-X86-64-BASIC: "-plugin-opt=O3"
 // CHECK-X86-64-BASIC: "-plugin-opt=foo"
 //
 // RUN: %clang -target x86_64-unknown-linux -### %t.o -flto 2>&1 \
-// RUN: -march=corei7 -Wl,-plugin-opt=foo \
+// RUN: -march=corei7 -Wl,-plugin-opt=foo -Ofast \
 // RUN: | FileCheck %s --check-prefix=CHECK-X86-64-COREI7
 // CHECK-X86-64-COREI7: "-plugin" "{{.*}}/LLVMgold.so"
 // CHECK-X86-64-COREI7: "-plugin-opt=mcpu=corei7"
+// CHECK-X86-64-COREI7: "-plugin-opt=O3"
 // CHECK-X86-64-COREI7: "-plugin-opt=foo"
 //
 // RUN: %clang -target arm-unknown-linux -### %t.o -flto 2>&1 \
-// RUN: -march=armv7a -Wl,-plugin-opt=foo \
+// RUN: -march=armv7a -Wl,-plugin-opt=foo -O0 \
 // RUN: | FileCheck %s --check-prefix=CHECK-ARM-V7A
 // CHECK-ARM-V7A: "-plugin" "{{.*}}/LLVMgold.so"
 // CHECK-ARM-V7A: "-plugin-opt=mcpu=cortex-a8"
+// CHECK-ARM-V7A: "-plugin-opt=O0"
 // CHECK-ARM-V7A: "-plugin-opt=foo"
 //
 // RUN: %clang -target i686-linux-android -### %t.o -flto 2>&1 \
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -1804,6 +1804,21 @@
   if (!CPU.empty())
 CmdArgs.push_back(Args.MakeArgString(Twine("-plugin-opt=mcpu=") + CPU));
 
+  if (Arg *A = Args.getLastArg(options::OPT_O_Group)) {
+if (A->getOption().matches(options::OPT_O4) ||
+A->getOption().matches(options::OPT_Ofast)) {
+  CmdArgs.push_back("-plugin-opt=O3");
+} else if (A->getOption().matches(options::OPT_O)) {
+  CmdArgs.push_back(
+  Args.MakeArgString(Twine("-plugin-opt=O") + A->getValue()));
+} else if (A->getOption().matches(options::OPT_O0)) {
+  CmdArgs.push_back("-plugin-opt=O0");
+} else {
+  

Re: [PATCH] D15641: [Driver] Pass -O* to the gold plugin via -plugin-opt

[James Molloy via cfe-commits]

Hi Joerg,

This is about the standard generic optimizer flags. Currently when using
-flto, the backend behaves always as if "-O2" were passed (because this is
the default codegen optimization level inside the gold plugin and it's
never overridden!). So CodeGenOpt::Aggressive is never picked, and that can
significantly change the backend's behaviour.

This isn't about linker optimizations.

James

On Fri, 18 Dec 2015 at 15:50 Joerg Sonnenberger via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Fri, Dec 18, 2015 at 01:53:58PM +, James Molloy wrote:
> > The gold plugin understands -O0..-O3, but these are not currently being
> passed to it.
>
> Is this about generic optimizer flags in the sense of things that get
> back to LLVM or about linker-style optimizations?
>
> Joerg
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D15641: [Driver] Pass -O* to the gold plugin via -plugin-opt

[James Molloy via cfe-commits]

jmolloy added a comment.

Hi Rafael,

Thanks for the review!

> This introduces a meaning to -ON during the link. That normally show up by 
> people passing CFLAGS when linking.


Yes. The rationale is that with -flto, the link is also part of the compile. I 
think it's more surprising that the compiler isn't called with the -O options 
than the reverse!

James



Comment at: lib/Driver/Tools.cpp:1815
@@ +1814,3 @@
+} else if (A->getOption().matches(options::OPT_O0)) {
+  CmdArgs.push_back("-plugin-opt=O0");
+} else {

rafael wrote:
> Can you refactor these 3 calls to push_back?
Sure!


Comment at: lib/Driver/Tools.cpp:1817
@@ +1816,3 @@
+} else {
+  ToolChain.getDriver().Diag(clang::diag::warn_drv_unused_argument)
+  << A->getAsString(Args);

rafael wrote:
> Why do you need to manually issue a diagnostic?
> 
You're right - I don't. I'll remove this.


Repository:
  rL LLVM

http://reviews.llvm.org/D15641



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

Re: [PATCH] D15641: [Driver] Pass -O* to the gold plugin via -plugin-opt

[James Molloy via cfe-commits]

Evidently not, at least not completely. I see codegen differences with this
patch (and at least one significant improvement).

James
On Fri, 18 Dec 2015 at 16:31, Joerg Sonnenberger via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Fri, Dec 18, 2015 at 03:59:03PM +0000, James Molloy via cfe-commits
> wrote:
> > This is about the standard generic optimizer flags. Currently when using
> > -flto, the backend behaves always as if "-O2" were passed (because this
> is
> > the default codegen optimization level inside the gold plugin and it's
> > never overridden!). So CodeGenOpt::Aggressive is never picked, and that
> can
> > significantly change the backend's behaviour.
>
> I thought we moved to per-function optimissation attributes?
>
> Joerg
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D15641: [Driver] Pass -O* to the gold plugin via -plugin-opt

[James Molloy via cfe-commits]

Hi,

I'll take a look and see what actual codepath is being triggered. That
might give us some insight into the current behaviour. Because like you I
don't like doing things when we don't exactly know why they're necessary.

James

On Fri, 18 Dec 2015 at 17:48 Joerg Sonnenberger via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Fri, Dec 18, 2015 at 05:31:45PM +0000, James Molloy via cfe-commits
> wrote:
> > Evidently not, at least not completely. I see codegen differences with
> this
> > patch (and at least one significant improvement).
>
> I don't mind the patch as is, but it seems to be a move in the wrong
> direction by hiding the real issue. Just saying.
>
> Joerg
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D15223: [ARM] [AARCH64] Add CodeGen IR tests for {VS}QRDML{AS}H v8.1a intrinsics.

[James Molloy via cfe-commits]

Fwiw, I am certainly in Tim'a camp here! Writing a test for that output is
doable, and if that's what people want then that's what we'll do. But it's
certainly not nice or readable !
On Mon, 14 Dec 2015 at 19:25, Tim Northover via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On 14 December 2015 at 11:12, Eric Christopher  wrote:
> > There really is a pretty good separation of concerns and for a lot if not
> > most of the tests here all the difference is checking is the arguments,
> > keeping track of an alloca and making sure that goes is pretty simple and
> > not really hard for a test.
>
> And the rest! This us the output for a trivial function: vqrdmulh_s16:
>
> define <4 x i16> @foo(<4 x i16> %l, <4 x i16> %r) #0 {
> entry:
>   %__p0.addr.i = alloca <4 x i16>, align 8
>   %__p1.addr.i = alloca <4 x i16>, align 8
>   %__ret.i = alloca <4 x i16>, align 8
>   %l.addr = alloca <4 x i16>, align 8
>   %r.addr = alloca <4 x i16>, align 8
>   store <4 x i16> %l, <4 x i16>* %l.addr, align 8
>   store <4 x i16> %r, <4 x i16>* %r.addr, align 8
>   %0 = load <4 x i16>, <4 x i16>* %l.addr, align 8
>   %1 = load <4 x i16>, <4 x i16>* %r.addr, align 8
>   store <4 x i16> %0, <4 x i16>* %__p0.addr.i, align 8
>   store <4 x i16> %1, <4 x i16>* %__p1.addr.i, align 8
>   %2 = load <4 x i16>, <4 x i16>* %__p0.addr.i, align 8
>   %3 = bitcast <4 x i16> %2 to <8 x i8>
>   %4 = load <4 x i16>, <4 x i16>* %__p1.addr.i, align 8
>   %5 = bitcast <4 x i16> %4 to <8 x i8>
>   %vqrdmulh_v.i = bitcast <8 x i8> %3 to <4 x i16>
>   %vqrdmulh_v1.i = bitcast <8 x i8> %5 to <4 x i16>
>   %vqrdmulh_v2.i = call <4 x i16> @llvm.arm.neon.vqrdmulh.v4i16(<4 x
> i16> %vqrdmulh_v.i, <4 x i16> %vqrdmulh_v1.i) #2
>   %vqrdmulh_v3.i = bitcast <4 x i16> %vqrdmulh_v2.i to <8 x i8>
>   %6 = bitcast <8 x i8> %vqrdmulh_v3.i to <4 x i16>
>   store <4 x i16> %6, <4 x i16>* %__ret.i, align 8
>   %7 = load <4 x i16>, <4 x i16>* %__ret.i, align 8
>   ret <4 x i16> %7
> }
>
> Is that right? Hope so, but I'm buggered if I know. And when anyone
> looks at a test based on that they've got to thread 3 datapaths
> through about 6 stages each without getting confused to work it out.
> Possible, but for the tiny beneficial fuzzies we get from not running
> opt, not worth it in my opinion.
>
> Tim.
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D15223: [ARM] [AARCH64] Add CodeGen IR tests for {VS}QRDML{AS}H v8.1a intrinsics.

[James Molloy via cfe-commits]

jmolloy resigned from this revision.
jmolloy removed a reviewer: jmolloy.
jmolloy added a comment.

Eric is reviewing this; resigning myself.


http://reviews.llvm.org/D15223



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

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[James Molloy via cfe-commits]

Hi Eric,

This isn't just a NEON intrinsics thing, and this isn't just an ARM/AArch64
thing. There needs to be some way to test the compiler from start to
finish. Not being able to do so leaves serious coverage holes.

Unit testing is great, but integration testing is required sometimes to
ensure multiple units interface as expected. I could grab a bunch of
examples from the clang tests directory that my grep has just thrown up -
CodeGen/nobuiltin.c, for example, or
CodeGen/aarch64-fix-cortex-a53-835769.c, where we absolutely 100% must
ensure that the -mfix-cortex-a53-835769 flag gets properly respected in the
compiler output.

If you can describe a way to get the same strength of testing without
running the backend during clang tests, I'm all ears!

James

On Tue, 1 Dec 2015 at 16:59 Eric Christopher  wrote:

> Hi James,
>
> I disagree with you completely on every point except that you need to
> write new tests.
>
> There is absolutely, as I said in the thread where I noticed this for the
> x86 intrinsics, that you cannot supply this test up and test it in the
> front and the back end separately. If you believe this is impossible please
> let me know why, but clang and llvm are designed to be tested as I stated.
> As far as prior art, I can only apologize that I didn't see them before,
> I'm sure you know how hard it is to review everything.
>
> Thanks
>
> -eric
>
> On Tue, Dec 1, 2015, 3:44 AM James Molloy  wrote:
>
> Hi Eric,
>
> While I agree with you in principle, Alexandros has just pointed out to me
> that all the other NEON intrinsics have such -O3 tests, and thinking about
> it I do think they add value. They test the full-trip through the compiler
> and ensure that Clang and LLVM have matching ideas of the IR interface
> exposed by the intrinsics.
>
> AIUI, Alexandros wrote LLVM backend tests in addition to these. It does
> look like there are no tests just checking Clang's IR output - I think
> these should indeed be written.
>
> In summary, I agree with you that we need tests for both Clang and LLVM
> separately. However I also think the full-trip tests add significant value
> and wouldn't like to see them removed, and there's significant prior art in
> this area so if we did decide they needed to be gone, we'd need a good
> discussion on how to regain the testing coverage we'd lose.
>
>
>
> Cheers,
>
> James
>
> On Sun, 29 Nov 2015 at 20:40 Eric Christopher via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> Hi,
>
> This is entirely the wrong way to do these tests. They shouldn't depend on
> assembly output or optimization. Please split them onto frontend IR tests
> and backend assembly tests.
>
> Thanks!
>
> On Sun, Nov 29, 2015, 2:56 AM Alexandros Lamprineas via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> Author: alelab01
> Date: Sun Nov 29 04:53:28 2015
> New Revision: 254251
>
> URL: http:// 
> llvm.org /
> viewvc
> /
> llvm-project
> 
> ?rev=254251=rev
> 
> Log:
> ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply
> Add/Subtract.
>
> Add missing tests that accidentally were not committed in rL254250.
>
> Differential Revision: http:// 
> reviews.llvm.org /D14982
> 
>
> Added:
> cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c
> cfe/trunk/test/CodeGen/arm-v8.1a-neon-intrinsics.c
>
> Added: cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c
> URL: http://
> 
> llvm.org
> 
> /
> 
> viewvc
> 
> /
> 
> llvm-project
> 
> /
> 
> cfe
> 
> /trunk/test/
> 
> CodeGen
> 

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[James Molloy via cfe-commits]

Hi,

> That would sort of defeat the point of having the testing and projects
separated though - it would tie the tests together and produce most of the
undesirable outcomes of having single end-to-end tests.

End to end tests have significant disadvantages as we all know. However
they do have some advantages too( that I have already enumerated) and the
question currently as I see it is how do we best get/keep those advantages
in our testing strategy?

W.r.t the test-suite, that is a possibility. There are currently no
codegen-filecheck tests in the test-suite but there seems to be no reason I
can see why not. The disadvantage there for me is that we take short
running, simple tests and demote them to be run less often.

Would it make sense to have a dedicated subdirectory in clang/test for
these kind of tests, so they can be directly enumerated and therefore kept
to a minimum , yet be allowed when they add value?

James
On Tue, 1 Dec 2015 at 18:29, David Blaikie <dblai...@gmail.com> wrote:

> On Tue, Dec 1, 2015 at 9:56 AM, Renato Golin via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> On 1 December 2015 at 17:23, James Molloy via cfe-commits
>> <cfe-commits@lists.llvm.org> wrote:
>> > This isn't just a NEON intrinsics thing, and this isn't just an
>> ARM/AArch64
>> > thing. There needs to be some way to test the compiler from start to
>> finish.
>> > Not being able to do so leaves serious coverage holes.
>>
>> Just for the sake of completeness, a hole that the test-suite doesn't
>> cover.
>>
>
> Are they things the test-suite couldn't (either technically or
> philosophically) cover, or only that it doesn't cover it at the moment, but
> could do so?
>
>
>>
>>
>> > CodeGen/aarch64-fix-cortex-a53-835769.c, where we absolutely 100% must
>> > ensure that the -mfix-cortex-a53-835769 flag gets properly respected in
>> the
>> > compiler output.
>>
>> SIMD intrinsics (including NEON, SSE), Errata fixes, Procedure call
>> tests, ELF section placement, FP contracts, Debug info, Inline
>> assembly, Unicode support, object creation, library symbol clashes,
>> back-end diagnostics are some of the examples that need to go all the
>> way to asm or object code.
>>
>>
>> > If you can describe a way to get the same strength of testing without
>> > running the backend during clang tests, I'm all ears!
>>
>> I'm particularly interested in how do we keep the IR printed in the
>> Clang tests in sync with the IR sent to the LLVM tests if/when they
>> change, to guarantee that Clang changes don't generate silent codegen
>> faults down the line in LLVM and vice-versa.
>>
>
> That would sort of defeat the point of having the testing and projects
> separated though - it would tie the tests together and produce most of the
> undesirable outcomes of having single end-to-end tests.
>
> (it would mean that at least the pure (or at least non-Clang) LLVM
> developer would have a test to run where they would not if the test
> remained in Clang only)
>
>
>>
>> cheers,
>> --renato
>
>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[James Molloy via cfe-commits]

You cannot test the intrinsic emission with the same quality when splitting
the test in two. You miss testing the producer consumer relationship
between the two components.

I'm sorry that this use case appears to you as not qualifying.
On Tue, 1 Dec 2015 at 18:45, Eric Christopher <echri...@gmail.com> wrote:

> On Tue, Dec 1, 2015 at 10:43 AM James Molloy via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Hi,
>>
>> > That would sort of defeat the point of having the testing and projects
>> separated though - it would tie the tests together and produce most of the
>> undesirable outcomes of having single end-to-end tests.
>>
>> End to end tests have significant disadvantages as we all know. However
>> they do have some advantages too( that I have already enumerated) and the
>> question currently as I see it is how do we best get/keep those advantages
>> in our testing strategy?
>>
>> W.r.t the test-suite, that is a possibility. There are currently no
>> codegen-filecheck tests in the test-suite but there seems to be no reason I
>> can see why not. The disadvantage there for me is that we take short
>> running, simple tests and demote them to be run less often.
>>
>> Would it make sense to have a dedicated subdirectory in clang/test for
>> these kind of tests, so they can be directly enumerated and therefore kept
>> to a minimum , yet be allowed when they add value?
>>
>>
> There are a few cases where we can't currently test something, but none of
> the cases you or Renato have brought up qualify. I'm curious what you'd put
> in this directory?
>
> -eric
>
>
>> James
>> On Tue, 1 Dec 2015 at 18:29, David Blaikie <dblai...@gmail.com> wrote:
>>
>>> On Tue, Dec 1, 2015 at 9:56 AM, Renato Golin via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
>>>> On 1 December 2015 at 17:23, James Molloy via cfe-commits
>>>> <cfe-commits@lists.llvm.org> wrote:
>>>> > This isn't just a NEON intrinsics thing, and this isn't just an
>>>> ARM/AArch64
>>>> > thing. There needs to be some way to test the compiler from start to
>>>> finish.
>>>> > Not being able to do so leaves serious coverage holes.
>>>>
>>>> Just for the sake of completeness, a hole that the test-suite doesn't
>>>> cover.
>>>>
>>>
>>> Are they things the test-suite couldn't (either technically or
>>> philosophically) cover, or only that it doesn't cover it at the moment, but
>>> could do so?
>>>
>>>
>>>>
>>>>
>>>> > CodeGen/aarch64-fix-cortex-a53-835769.c, where we absolutely 100% must
>>>> > ensure that the -mfix-cortex-a53-835769 flag gets properly respected
>>>> in the
>>>> > compiler output.
>>>>
>>>> SIMD intrinsics (including NEON, SSE), Errata fixes, Procedure call
>>>> tests, ELF section placement, FP contracts, Debug info, Inline
>>>> assembly, Unicode support, object creation, library symbol clashes,
>>>> back-end diagnostics are some of the examples that need to go all the
>>>> way to asm or object code.
>>>>
>>>>
>>>> > If you can describe a way to get the same strength of testing without
>>>> > running the backend during clang tests, I'm all ears!
>>>>
>>>> I'm particularly interested in how do we keep the IR printed in the
>>>> Clang tests in sync with the IR sent to the LLVM tests if/when they
>>>> change, to guarantee that Clang changes don't generate silent codegen
>>>> faults down the line in LLVM and vice-versa.
>>>>
>>>
>>> That would sort of defeat the point of having the testing and projects
>>> separated though - it would tie the tests together and produce most of the
>>> undesirable outcomes of having single end-to-end tests.
>>>
>>> (it would mean that at least the pure (or at least non-Clang) LLVM
>>> developer would have a test to run where they would not if the test
>>> remained in Clang only)
>>>
>>>
>>>>
>>>> cheers,
>>>> --renato
>>>
>>>
>>>> ___
>>>> cfe-commits mailing list
>>>> cfe-commits@lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>>
>>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[James Molloy via cfe-commits]

Hi,

FWIW, I'm happy with moving these tests into the test-suite. They do make
sense to be expressed in a compiler-neutral manner, even though some may
test clang-specific behaviour.

There is a UnitTests directory already, and adding the ability to run LIT
tests should be simple within the new CMake framework.

James
On Tue, 1 Dec 2015 at 19:09, David Blaikie  wrote:

> On Tue, Dec 1, 2015 at 10:43 AM, Renato Golin 
> wrote:
>
>> On 1 December 2015 at 18:29, David Blaikie  wrote:
>> > Are they things the test-suite couldn't (either technically or
>> > philosophically) cover, or only that it doesn't cover it at the moment,
>> but
>> > could do so?
>>
>> IMO, it's a philosophical issue. The test-suite is a whole-program
>> execution, and all that matters is the end result, the output of the
>> program, not the program itself.
>>
>> Those tests are mostly large (> 3 lines of code) so, if we were trying
>> to objdump and match for instruction patterns, any optimisation
>> variance could destroy them, as well as you may find the pattern
>> elsewhere in the same object, not belonging to the function you want
>> (inlining, etc).
>
>
> Not sure I follow - I'm not suggesting adding objdump/instruction checking
> to existing large programs in the test-suite, but adding other tests to the
> test-suite that do this and have appropriate input for it to be a
> reliable/useful form of testing.
>
>
>> All in all, all the problems with reducing C code
>> would be pertinent here, so a big hammer to kill small issues. On the
>> other hand, the Clang based asm/obj examples are all small, and
>> hand-crafted to suit the problem being tested.
>>
>> We could, however, add a new directory in the test-suite for that kind
>> of tests, like we already have for regressions in C/C++.
>
>
> If a separate directory makes it more clear what the purpose is, sure,
> seems fine to me, but I don't have strong or informed opinions on exactly
> how the test-suite is laid out.
>
>
>> That would
>> dissociate the front-end from the back-end, and essentially any
>> compiler used would have to abide by the rules of the test (which may
>> not be true for some compilers).
>>
>
> This is perhaps an interesting part/point: In theory I would think that
> these tests should be able to be phrased in a compiler-agnostic way, since
> they're testing the compiler as a whole and testing behavior that the
> source code demands, no?
>
>
>> I don't mind where they end up, really, but we need that kind of test
>> somewhere. Clang is an easy place because we know we have it built
>> when the Clang repo is checked out.
>>
>>
>> > That would sort of defeat the point of having the testing and projects
>> > separated though - it would tie the tests together and produce most of
>> the
>> > undesirable outcomes of having single end-to-end tests.
>>
>> Right, I agree, but since the relationship between Clang and LLVM is
>> non-trivial, and there are lots of changes that need to be done on
>> both sides, I can't see why we shouldn't have tests that span across
>> projects.
>>
>> Clearly, the sanitizer tests need Clang and Compiler-RT. Some Libc++
>> tests need Compiler-RT, others need libunwind, on ARM I need Clang to
>> build it. There are a lot of dependencies that are not there by
>> accident, but by design.
>>
>> The more you move tests away from the big targets (LLVM, Clang), the
>> less they're ran by people committing patches, and the harder will be
>> to pick up the failures. Having said that, a decent buildbot coverage
>> would account for most of those problems, but it would also put a
>> stress on slow/expensive/experimental hardware support. It's a
>> balance, I think.
>>
>
> Why would it require slow/expensive/experimental hardware? (& if it does
> require that, how do you expect average developers to run them on a regular
> basis?)
>
>
>>
>>
>> > (it would mean that at least the pure (or at least non-Clang) LLVM
>> developer
>> > would have a test to run where they would not if the test remained in
>> Clang
>> > only)
>>
>> That is a good point. Right now, RT/libc++ tests in that category are
>> controlled by enabling/disabling support via CMake flags. We may be
>> able to do the same with Clang (if LLVM is not built with it, disable
>> asm/obj tests). Moving them all to a regression package in the
>> test-suite would be another option, but one that would take a lot
>> longer...
>>
>> cheers,
>> --renato
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[James Molloy via cfe-commits]

Hi Renato,

> by a non-trivial amount.

Why do you think it would be non trivial? Some simple lit tests aren't
exactly arduous on most targets.

James
On Tue, 1 Dec 2015 at 19:39, Renato Golin  wrote:

> On 1 December 2015 at 19:09, David Blaikie  wrote:
> > Not sure I follow - I'm not suggesting adding objdump/instruction
> checking
> > to existing large programs in the test-suite, but adding other tests to
> the
> > test-suite that do this and have appropriate input for it to be a
> > reliable/useful form of testing.
>
> Sorry, I was building to that... But currently, the test-suite
> compiles the code into an executable, then run it. Changing that
> premise means we'll have something other than the test-suite we always
> had, and may bring other problems, like too many hats for the
> infrastructure to keep, especially now that James is moving it to
> integrate with lit. We may decide this is the way to go, but we need
> to make clear all the pros and cons of doing so beforehand.
>
>
> > This is perhaps an interesting part/point: In theory I would think that
> > these tests should be able to be phrased in a compiler-agnostic way,
> since
> > they're testing the compiler as a whole and testing behavior that the
> source
> > code demands, no?
>
> There's where things get interesting. Say we change the test-suite to
> instead of compiling and running, just compile to asm/obj and
> grep/objdump to match instructions, ELF sections, debug symbols, etc.
>
> Some tests are easy to make compiler independent. Intrinsics tests
> fall into that category. Most currently in Clang tests could move
> directly to the test-suite as soon as we have such infrastructure.
>
> Other tests, however, are specific to Clang+LLVM that may make no
> sense to GCC or ICC, ARMCC etc. Those tests, would have to be in yet
> another separate directory, that is only enabled if the compiler is
> Clang, assuming the back-end is always LLVM.
>
> These are all options that, for me, have equal value with keeping them
> in Clang. AFAICS, they stir the same kind of problems wherever they
> are tested.
>
>
> >> would account for most of those problems, but it would also put a
> >> stress on slow/expensive/experimental hardware support. It's a
> >> balance, I think.
> >
> > Why would it require slow/expensive/experimental hardware? (& if it does
> > require that, how do you expect average developers to run them on a
> regular
> > basis?)
>
> You misunderstood. It would "put a stress on", not "require".
> Basically, it would increase the cost of testing on those classes of
> hardware more than off-the-shelf hardware by a non-trivial amount.
>
> This goes back to our discussion on buildbots, where some targets are
> harder to find hardware than others, and when you do, they're slower.
> Meaning the more variations we need to test, the more hardware you
> have to have to make it in any reasonable time. While a single 64-core
> Xeon can cope with most testing (including self-hosting, test-suite,
> sanitizers, libc++) on a per-commit basis, there is nothing similar,
> widely available, today for most other targets.
>
> But that's another discussion entirely, let's not dwell into that again. :)
>
> cheers,
> --renato
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[James Molloy via cfe-commits]

Ok, understood.

I think I'd be OK with demoting these tests to the test-suite, and dealing
with the slightly lower amount of testing that comes with it if it means we
can keep the clang tests in a nice shape.

We'd need to ensure there were equivalent tests written that test only
clang produced IR - many tests will have this already but some don't.

James
On Tue, 1 Dec 2015 at 19:51, Renato Golin  wrote:

> On 1 December 2015 at 19:42, James Molloy  wrote:
> > Why do you think it would be non trivial? Some simple lit tests aren't
> > exactly arduous on most targets.
>
> I mean having more points in the testing matrix.
>
> Clang check-all is cheaper than running the test-suite, but if we
> start moving more tests to the suite, we'll have to run it for more
> combinations. For slow targets, that mostly means a new buildbot,
> because you want the "fast" check-all to not be impeded by the "slow"
> test-suite for every commit.
>
> The "non-trivial" amount is the sole difference in how many machines
> you can get to have a reasonable amount of commits in the blame-list
> for everything we test, which is trivial on fast x86_64 servers.
>
> --renato
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[James Molloy via cfe-commits]

Hi Eric,

While I agree with you in principle, Alexandros has just pointed out to me
that all the other NEON intrinsics have such -O3 tests, and thinking about
it I do think they add value. They test the full-trip through the compiler
and ensure that Clang and LLVM have matching ideas of the IR interface
exposed by the intrinsics.

AIUI, Alexandros wrote LLVM backend tests in addition to these. It does
look like there are no tests just checking Clang's IR output - I think
these should indeed be written.

In summary, I agree with you that we need tests for both Clang and LLVM
separately. However I also think the full-trip tests add significant value
and wouldn't like to see them removed, and there's significant prior art in
this area so if we did decide they needed to be gone, we'd need a good
discussion on how to regain the testing coverage we'd lose.

Cheers,

James

On Sun, 29 Nov 2015 at 20:40 Eric Christopher via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Hi,
>
> This is entirely the wrong way to do these tests. They shouldn't depend on
> assembly output or optimization. Please split them onto frontend IR tests
> and backend assembly tests.
>
> Thanks!
>
> On Sun, Nov 29, 2015, 2:56 AM Alexandros Lamprineas via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: alelab01
>> Date: Sun Nov 29 04:53:28 2015
>> New Revision: 254251
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=254251=rev
>> Log:
>> ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply
>> Add/Subtract.
>>
>> Add missing tests that accidentally were not committed in rL254250.
>>
>> Differential Revision: http://reviews.llvm.org/D14982
>>
>> Added:
>> cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c
>> cfe/trunk/test/CodeGen/arm-v8.1a-neon-intrinsics.c
>>
>> Added: cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c?rev=254251=auto
>>
>> ==
>> --- cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c (added)
>> +++ cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c Sun Nov 29
>> 04:53:28 2015
>> @@ -0,0 +1,128 @@
>> +// REQUIRES: aarch64-registered-target
>> +
>> +// RUN: %clang_cc1 -triple aarch64-linux-gnu -target-feature +neon \
>> +// RUN:  -target-feature +v8.1a -O3 -S -o - %s \
>> +// RUN:  | FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-AARCH64
>> +
>> + #include 
>> +
>> +// CHECK-AARCH64-LABEL: test_vqrdmlah_laneq_s16
>> +int16x4_t test_vqrdmlah_laneq_s16(int16x4_t a, int16x4_t b, int16x8_t v)
>> {
>> +// CHECK-AARCH64: sqrdmlah {{v[0-9]+}}.4h, {{v[0-9]+}}.4h,
>> {{v[0-9]+}}.h[7]
>> +  return vqrdmlah_laneq_s16(a, b, v, 7);
>> +}
>> +
>> +// CHECK-AARCH64-LABEL: test_vqrdmlah_laneq_s32
>> +int32x2_t test_vqrdmlah_laneq_s32(int32x2_t a, int32x2_t b, int32x4_t v)
>> {
>> +// CHECK-AARCH64: sqrdmlah {{v[0-9]+}}.2s, {{v[0-9]+}}.2s,
>> {{v[0-9]+}}.s[3]
>> +  return vqrdmlah_laneq_s32(a, b, v, 3);
>> +}
>> +
>> +// CHECK-AARCH64-LABEL: test_vqrdmlahq_laneq_s16
>> +int16x8_t test_vqrdmlahq_laneq_s16(int16x8_t a, int16x8_t b, int16x8_t
>> v) {
>> +// CHECK-AARCH64: sqrdmlah {{v[0-9]+}}.8h, {{v[0-9]+}}.8h,
>> {{v[0-9]+}}.h[7]
>> +  return vqrdmlahq_laneq_s16(a, b, v, 7);
>> +}
>> +
>> +// CHECK-AARCH64-LABEL: test_vqrdmlahq_laneq_s32
>> +int32x4_t test_vqrdmlahq_laneq_s32(int32x4_t a, int32x4_t b, int32x4_t
>> v) {
>> +// CHECK-AARCH64: sqrdmlah {{v[0-9]+}}.4s, {{v[0-9]+}}.4s,
>> {{v[0-9]+}}.s[3]
>> +  return vqrdmlahq_laneq_s32(a, b, v, 3);
>> +}
>> +
>> +// CHECK-AARCH64-LABEL: test_vqrdmlahh_s16
>> +int16_t test_vqrdmlahh_s16(int16_t a, int16_t b, int16_t c) {
>> +// CHECK-AARCH64: sqrdmlah {{h[0-9]+|v[0-9]+.4h}},
>> {{h[0-9]+|v[0-9]+.4h}}, {{h[0-9]+|v[0-9]+.4h}}
>> +  return vqrdmlahh_s16(a, b, c);
>> +}
>> +
>> +// CHECK-AARCH64-LABEL: test_vqrdmlahs_s32
>> +int32_t test_vqrdmlahs_s32(int32_t a, int32_t b, int32_t c) {
>> +// CHECK-AARCH64: sqrdmlah {{s[0-9]+}}, {{s[0-9]+}}, {{s[0-9]+}}
>> +  return vqrdmlahs_s32(a, b, c);
>> +}
>> +
>> +// CHECK-AARCH64-LABEL: test_vqrdmlahh_lane_s16
>> +int16_t test_vqrdmlahh_lane_s16(int16_t a, int16_t b, int16x4_t c) {
>> +// CHECK-AARCH64: sqrdmlah {{h[0-9]+|v[0-9]+.4h}},
>> {{h[0-9]+|v[0-9]+.4h}}, {{v[0-9]+}}.h[3]
>> +  return vqrdmlahh_lane_s16(a, b, c, 3);
>> +}
>> +
>> +// CHECK-AARCH64-LABEL: test_vqrdmlahs_lane_s32
>> +int32_t test_vqrdmlahs_lane_s32(int32_t a, int32_t b, int32x2_t c) {
>> +// CHECK-AARCH64: sqrdmlah {{s[0-9]+}}, {{s[0-9]+}}, {{v[0-9]+}}.s[1]
>> +  return vqrdmlahs_lane_s32(a, b, c, 1);
>> +}
>> +
>> +// CHECK-AARCH64-LABEL: test_vqrdmlahh_laneq_s16
>> +int16_t test_vqrdmlahh_laneq_s16(int16_t a, int16_t b, int16x8_t c) {
>> +// CHECK-AARCH64: sqrdmlah {{h[0-9]+|v[0-9]+.4h}},
>> {{h[0-9]+|v[0-9]+.4h}}, {{v[0-9]+}}.h[7]
>> +  return vqrdmlahh_laneq_s16(a, b, c, 7);
>> +}
>> +
>> +// CHECK-AARCH64-LABEL: test_vqrdmlahs_laneq_s32

Re: [PATCH] D14570: Handle ARMv6KZ naming

[James Molloy via cfe-commits]

Hi Renato,

Ideally, shouldn't the clang tests be checking that the LLVM target parsing
library is called with the correct arguments? then separate tests inside
LLVM check that the target parser works correctly?

As it stands, it seems like a very deliberate layering violation that could
really do with chopping up.

James

On Mon, 16 Nov 2015 at 12:19 Renato Golin via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> rengolin added a comment.
>
> In http://reviews.llvm.org/D14570#288132, @compnerd wrote:
>
> > Wow, this is tricky: the code change is in LLVM, and test change in
> clang :(.  However, this does seem to preserve the features.
>
>
> The problem is that Clang is the most important user of this library,
> which also has other users in LLVM. We just need to make sure that Clang is
> doing the right thing, and that the intentions are recorded on the right
> places. In this case, it's Clang. :)
>
>
> http://reviews.llvm.org/D14570
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r252872 - Update clang regression tests for 'norecurse'

[James Molloy via cfe-commits]

Author: jamesm
Date: Thu Nov 12 04:56:51 2015
New Revision: 252872

URL: http://llvm.org/viewvc/llvm-project?rev=252872=rev
Log:
Update clang regression tests for 'norecurse'

FunctionAttrs has just been taught how to infer 'norecurse'. Update clang tests 
for LLVM r252871.

Modified:
cfe/trunk/test/CodeGen/attr-minsize.cpp
cfe/trunk/test/CodeGen/function-attributes.c
cfe/trunk/test/CodeGenCXX/default-destructor-synthesis.cpp
cfe/trunk/test/CodeGenCXX/member-initializers.cpp
cfe/trunk/test/CodeGenCXX/pointers-to-data-members.cpp

Modified: cfe/trunk/test/CodeGen/attr-minsize.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/attr-minsize.cpp?rev=252872=252871=252872=diff
==
--- cfe/trunk/test/CodeGen/attr-minsize.cpp (original)
+++ cfe/trunk/test/CodeGen/attr-minsize.cpp Thu Nov 12 04:56:51 2015
@@ -76,4 +76,4 @@ void test5(float arg);
 
 // Oz: attributes [[MINSIZE]] = { minsize{{.*}} }
 
-// OTHER: attributes [[MS]] = { minsize nounwind{{.*}} }
+// OTHER: attributes [[MS]] = { minsize {{(norecurse )?}}nounwind{{.*}} }

Modified: cfe/trunk/test/CodeGen/function-attributes.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/function-attributes.c?rev=252872=252871=252872=diff
==
--- cfe/trunk/test/CodeGen/function-attributes.c (original)
+++ cfe/trunk/test/CodeGen/function-attributes.c Thu Nov 12 04:56:51 2015
@@ -128,9 +128,9 @@ void f20(void) {
   _setjmp(0);
 }
 
-// CHECK: attributes [[NUW]] = { nounwind optsize readnone{{.*}} }
-// CHECK: attributes [[AI]] = { alwaysinline nounwind optsize readnone{{.*}} }
-// CHECK: attributes [[ALIGN]] = { nounwind optsize readnone 
alignstack=16{{.*}} }
+// CHECK: attributes [[NUW]] = { norecurse nounwind optsize readnone{{.*}} }
+// CHECK: attributes [[AI]] = { alwaysinline norecurse nounwind optsize 
readnone{{.*}} }
+// CHECK: attributes [[ALIGN]] = { norecurse nounwind optsize readnone 
alignstack=16{{.*}} }
 // CHECK: attributes [[RT]] = { nounwind optsize returns_twice{{.*}} }
 // CHECK: attributes [[NR]] = { noreturn nounwind optsize }
 // CHECK: attributes [[NUW_RN]] = { nounwind optsize readnone }

Modified: cfe/trunk/test/CodeGenCXX/default-destructor-synthesis.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/default-destructor-synthesis.cpp?rev=252872=252871=252872=diff
==
--- cfe/trunk/test/CodeGenCXX/default-destructor-synthesis.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/default-destructor-synthesis.cpp Thu Nov 12 
04:56:51 2015
@@ -35,4 +35,4 @@ int f() {
   return count;
 }
 
-// CHECK: attributes [[NUW]] = { nounwind{{.*}} }
+// CHECK: attributes [[NUW]] = { norecurse nounwind{{.*}} }

Modified: cfe/trunk/test/CodeGenCXX/member-initializers.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/member-initializers.cpp?rev=252872=252871=252872=diff
==
--- cfe/trunk/test/CodeGenCXX/member-initializers.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/member-initializers.cpp Thu Nov 12 04:56:51 2015
@@ -32,4 +32,4 @@ int test_fold() {
   return A(2).i;
 }
 
-// CHECK: attributes [[NUW_RN]] = { nounwind readnone{{.*}} }
+// CHECK: attributes [[NUW_RN]] = { norecurse nounwind readnone{{.*}} }

Modified: cfe/trunk/test/CodeGenCXX/pointers-to-data-members.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/pointers-to-data-members.cpp?rev=252872=252871=252872=diff
==
--- cfe/trunk/test/CodeGenCXX/pointers-to-data-members.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/pointers-to-data-members.cpp Thu Nov 12 04:56:51 
2015
@@ -295,4 +295,4 @@ U u;
 // CHECK-GLOBAL: @_ZN11IndirectPDM1uE = global %"union.IndirectPDM::U" { 
%union.anon { i64 -1 } }, align 8
 }
 
-// CHECK-O3: attributes [[NUW]] = { nounwind readnone{{.*}} }
+// CHECK-O3: attributes [[NUW]] = { norecurse nounwind readnone{{.*}} }


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

Re: [PATCH] D14615: [C++] Add the "norecurse" attribute to main() if in C++ mode

[James Molloy via cfe-commits]

jmolloy closed this revision.
jmolloy added a comment.

Thanks Aaron, committed in r252902.


Repository:
  rL LLVM

http://reviews.llvm.org/D14615



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

Re: [PATCH] D14615: [C++] Add the "norecurse" attribute to main() if in C++ mode

[James Molloy via cfe-commits]

jmolloy updated this revision to Diff 40050.
jmolloy added a comment.

Hi Aaron,

Thanks, this should all be fixed now.

Cheers,

James


Repository:
  rL LLVM

http://reviews.llvm.org/D14615

Files:
  lib/CodeGen/CodeGenFunction.cpp
  test/CodeGenCXX/main-norecurse.cpp
  test/CodeGenObjC/objc-literal-tests.m

Index: test/CodeGenObjC/objc-literal-tests.m
===
--- test/CodeGenObjC/objc-literal-tests.m
+++ test/CodeGenObjC/objc-literal-tests.m
@@ -94,4 +94,4 @@
   bar(^(void) { return YES; });
 }
 
-// CHECK: attributes [[NUW]] = { nounwind{{.*}} }
+// CHECK: attributes [[NUW]] = { {{(norecurse )?}}nounwind{{.*}} }
Index: test/CodeGenCXX/main-norecurse.cpp
===
--- /dev/null
+++ test/CodeGenCXX/main-norecurse.cpp
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -emit-llvm %s -o - | FileCheck %s
+
+// CHECK: define i{{.*}} @main({{.*}}) #0
+int main(int argc, char **argv) {
+return 1;
+}
+
+// CHECK: attributes #0 = { norecurse{{.*}} }
Index: lib/CodeGen/CodeGenFunction.cpp
===
--- lib/CodeGen/CodeGenFunction.cpp
+++ lib/CodeGen/CodeGenFunction.cpp
@@ -716,6 +716,14 @@
 }
   }
 
+  // If we're in C++ mode and the function name is "main", it is guaranteed
+  // to be norecurse by the standard (3.6.1.3 "The function main shall not be
+  // used within a program").
+  if (getLangOpts().CPlusPlus)
+if (const FunctionDecl *FD = dyn_cast_or_null(D))
+  if (FD->isMain())
+Fn->addFnAttr(llvm::Attribute::NoRecurse);
+  
   llvm::BasicBlock *EntryBB = createBasicBlock("entry", CurFn);
 
   // Create a marker to make it easy to insert allocas into the entryblock


Index: test/CodeGenObjC/objc-literal-tests.m
===
--- test/CodeGenObjC/objc-literal-tests.m
+++ test/CodeGenObjC/objc-literal-tests.m
@@ -94,4 +94,4 @@
   bar(^(void) { return YES; });
 }
 
-// CHECK: attributes [[NUW]] = { nounwind{{.*}} }
+// CHECK: attributes [[NUW]] = { {{(norecurse )?}}nounwind{{.*}} }
Index: test/CodeGenCXX/main-norecurse.cpp
===
--- /dev/null
+++ test/CodeGenCXX/main-norecurse.cpp
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -emit-llvm %s -o - | FileCheck %s
+
+// CHECK: define i{{.*}} @main({{.*}}) #0
+int main(int argc, char **argv) {
+return 1;
+}
+
+// CHECK: attributes #0 = { norecurse{{.*}} }
Index: lib/CodeGen/CodeGenFunction.cpp
===
--- lib/CodeGen/CodeGenFunction.cpp
+++ lib/CodeGen/CodeGenFunction.cpp
@@ -716,6 +716,14 @@
 }
   }
 
+  // If we're in C++ mode and the function name is "main", it is guaranteed
+  // to be norecurse by the standard (3.6.1.3 "The function main shall not be
+  // used within a program").
+  if (getLangOpts().CPlusPlus)
+if (const FunctionDecl *FD = dyn_cast_or_null(D))
+  if (FD->isMain())
+Fn->addFnAttr(llvm::Attribute::NoRecurse);
+  
   llvm::BasicBlock *EntryBB = createBasicBlock("entry", CurFn);
 
   // Create a marker to make it easy to insert allocas into the entryblock
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D14615: [C++] Add the "norecurse" attribute to main() if in C++ mode

[James Molloy via cfe-commits]

jmolloy added inline comments.


Comment at: test/CodeGenCXX/main-norecurse.cpp:1
@@ +1,2 @@
+// RUN: %clang_cc1 -emit-llvm %s -o -
+

Wow, I managed to forget in my copy-paste from another test to add "| FileCheck 
%s" here.

I'll update this before committing.


Repository:
  rL LLVM

http://reviews.llvm.org/D14615



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

[PATCH] D14615: [C++] Add the "norecurse" attribute to main() if in C++ mode

[James Molloy via cfe-commits]

jmolloy created this revision.
jmolloy added a reviewer: aaron.ballman.
jmolloy added a subscriber: cfe-commits.
jmolloy set the repository for this revision to rL LLVM.

The C++ spec (3.6.1.3) says "The function `main` shall not be used within a 
program". This implies that it cannot recurse, so add the norecurse attribute 
to help the midend out a bit.

Repository:
  rL LLVM

http://reviews.llvm.org/D14615

Files:
  lib/CodeGen/CodeGenFunction.cpp
  test/CodeGenCXX/main-norecurse.cpp
  test/CodeGenObjC/objc-literal-tests.m

Index: test/CodeGenObjC/objc-literal-tests.m
===
--- test/CodeGenObjC/objc-literal-tests.m
+++ test/CodeGenObjC/objc-literal-tests.m
@@ -94,4 +94,4 @@
   bar(^(void) { return YES; });
 }
 
-// CHECK: attributes [[NUW]] = { nounwind{{.*}} }
+// CHECK: attributes [[NUW]] = { {{(norecurse )?}}nounwind{{.*}} }
Index: test/CodeGenCXX/main-norecurse.cpp
===
--- /dev/null
+++ test/CodeGenCXX/main-norecurse.cpp
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -emit-llvm %s -o -
+
+// CHECK: define i{{.*}} @main({{.*}}) [[A:#.*]]
+int main(int argc, char **argv) {
+return 1;
+}
+
+// CHECK: attribute [[A]] = attributes { norecurse{{.*}} }
Index: lib/CodeGen/CodeGenFunction.cpp
===
--- lib/CodeGen/CodeGenFunction.cpp
+++ lib/CodeGen/CodeGenFunction.cpp
@@ -716,6 +716,14 @@
 }
   }
 
+  // If we're in C++ mode and the function name is "main", it is guaranteed
+  // to be norecurse by the standard (3.6.1.3 "The function main shall not be
+  // used within a program")
+  if (getLangOpts().CPlusPlus)
+if (const FunctionDecl *FD = dyn_cast_or_null(D))
+  if (FD->isMain())
+Fn->addFnAttr(llvm::Attribute::NoRecurse);
+  
   llvm::BasicBlock *EntryBB = createBasicBlock("entry", CurFn);
 
   // Create a marker to make it easy to insert allocas into the entryblock


Index: test/CodeGenObjC/objc-literal-tests.m
===
--- test/CodeGenObjC/objc-literal-tests.m
+++ test/CodeGenObjC/objc-literal-tests.m
@@ -94,4 +94,4 @@
   bar(^(void) { return YES; });
 }
 
-// CHECK: attributes [[NUW]] = { nounwind{{.*}} }
+// CHECK: attributes [[NUW]] = { {{(norecurse )?}}nounwind{{.*}} }
Index: test/CodeGenCXX/main-norecurse.cpp
===
--- /dev/null
+++ test/CodeGenCXX/main-norecurse.cpp
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -emit-llvm %s -o -
+
+// CHECK: define i{{.*}} @main({{.*}}) [[A:#.*]]
+int main(int argc, char **argv) {
+return 1;
+}
+
+// CHECK: attribute [[A]] = attributes { norecurse{{.*}} }
Index: lib/CodeGen/CodeGenFunction.cpp
===
--- lib/CodeGen/CodeGenFunction.cpp
+++ lib/CodeGen/CodeGenFunction.cpp
@@ -716,6 +716,14 @@
 }
   }
 
+  // If we're in C++ mode and the function name is "main", it is guaranteed
+  // to be norecurse by the standard (3.6.1.3 "The function main shall not be
+  // used within a program")
+  if (getLangOpts().CPlusPlus)
+if (const FunctionDecl *FD = dyn_cast_or_null(D))
+  if (FD->isMain())
+Fn->addFnAttr(llvm::Attribute::NoRecurse);
+  
   llvm::BasicBlock *EntryBB = createBasicBlock("entry", CurFn);
 
   // Create a marker to make it easy to insert allocas into the entryblock
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r252902 - [C++] Add the "norecurse" attribute to main() if in C++ mode

[James Molloy via cfe-commits]

Author: jamesm
Date: Thu Nov 12 09:36:04 2015
New Revision: 252902

URL: http://llvm.org/viewvc/llvm-project?rev=252902=rev
Log:
[C++] Add the "norecurse" attribute to main() if in C++ mode

The C++ spec (3.6.1.3) says "The function `main` shall not be used within a 
program". This implies that it cannot recurse, so add the norecurse attribute 
to help the midend out a bit.

Added:
cfe/trunk/test/CodeGenCXX/main-norecurse.cpp
Modified:
cfe/trunk/lib/CodeGen/CodeGenFunction.cpp
cfe/trunk/test/CodeGenObjC/objc-literal-tests.m

Modified: cfe/trunk/lib/CodeGen/CodeGenFunction.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenFunction.cpp?rev=252902=252901=252902=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenFunction.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenFunction.cpp Thu Nov 12 09:36:04 2015
@@ -716,6 +716,14 @@ void CodeGenFunction::StartFunction(Glob
 }
   }
 
+  // If we're in C++ mode and the function name is "main", it is guaranteed
+  // to be norecurse by the standard (3.6.1.3 "The function main shall not be
+  // used within a program").
+  if (getLangOpts().CPlusPlus)
+if (const FunctionDecl *FD = dyn_cast_or_null(D))
+  if (FD->isMain())
+Fn->addFnAttr(llvm::Attribute::NoRecurse);
+  
   llvm::BasicBlock *EntryBB = createBasicBlock("entry", CurFn);
 
   // Create a marker to make it easy to insert allocas into the entryblock

Added: cfe/trunk/test/CodeGenCXX/main-norecurse.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/main-norecurse.cpp?rev=252902=auto
==
--- cfe/trunk/test/CodeGenCXX/main-norecurse.cpp (added)
+++ cfe/trunk/test/CodeGenCXX/main-norecurse.cpp Thu Nov 12 09:36:04 2015
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -emit-llvm %s -o - | FileCheck %s
+
+// CHECK: define i{{.*}} @main({{.*}}) #0
+int main(int argc, char **argv) {
+return 1;
+}
+
+// CHECK: attributes #0 = { norecurse{{.*}} }

Modified: cfe/trunk/test/CodeGenObjC/objc-literal-tests.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenObjC/objc-literal-tests.m?rev=252902=252901=252902=diff
==
--- cfe/trunk/test/CodeGenObjC/objc-literal-tests.m (original)
+++ cfe/trunk/test/CodeGenObjC/objc-literal-tests.m Thu Nov 12 09:36:04 2015
@@ -94,4 +94,4 @@ void baz(void) {
   bar(^(void) { return YES; });
 }
 
-// CHECK: attributes [[NUW]] = { nounwind{{.*}} }
+// CHECK: attributes [[NUW]] = { {{(norecurse )?}}nounwind{{.*}} }


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

Re: [PATCH] D14570: Handle ARMv6KZ naming

[James Molloy via cfe-commits]

Hi Artyom,

Why isn't this just part of D14568?

Cheers,

James

On Wed, 11 Nov 2015 at 12:08 A. Skrobov via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> tyomitch created this revision.
> tyomitch added reviewers: rengolin, joerg, bogden.
> tyomitch added a subscriber: cfe-commits.
> Herald added subscribers: rengolin, aemerson.
>
> Update for clang tests for D14568
>
> http://reviews.llvm.org/D14570
>
> Files:
>   test/Driver/arm-cortex-cpus.c
>   test/Driver/biarch.c
>
> Index: test/Driver/biarch.c
> ===
> --- test/Driver/biarch.c
> +++ test/Driver/biarch.c
> @@ -6,8 +6,9 @@
>  // RUN: %clang -target x86_64--netbsd -m64 %s -### 2>&1 | FileCheck
> -check-prefix=X86_64 %s
>  // X86_64: "-cc1" "-triple" "x86_64--netbsd"
>
> +// r196538 set arm1176jzf-s as default CPU for ARMv6 on NetBSD
>  // RUN: %clang -target armv6--netbsd-eabihf -m32 %s -### 2>&1 | FileCheck
> -check-prefix=ARMV6 %s
> -// ARMV6: "-cc1" "-triple" "armv6k--netbsd-eabihf"
> +// ARMV6: "-cc1" "-triple" "armv6kz--netbsd-eabihf"
>
>  // RUN: %clang -target sparcv9--netbsd -m32 %s -### 2>&1 | FileCheck
> -check-prefix=SPARC %s
>  // RUN: %clang -target sparc--netbsd -m32 %s -### 2>&1 | FileCheck
> -check-prefix=SPARC %s
> Index: test/Driver/arm-cortex-cpus.c
> ===
> --- test/Driver/arm-cortex-cpus.c
> +++ test/Driver/arm-cortex-cpus.c
> @@ -73,11 +73,11 @@
>
>  // RUN: %clang -target armv6k -### -c %s 2>&1 | FileCheck
> -check-prefix=CHECK-V6K %s
>  // RUN: %clang -target arm -march=armv6k -### -c %s 2>&1 | FileCheck
> -check-prefix=CHECK-V6K %s
> -// CHECK-V6K: "-cc1"{{.*}} "-triple" "armv6k-{{.*}} "-target-cpu"
> "arm1176jzf-s"
> +// CHECK-V6K: "-cc1"{{.*}} "-triple" "armv6k-{{.*}} "-target-cpu"
> "arm1176j-s"
>
>  // RUN: %clang -target armv6k -mthumb -### -c %s 2>&1 | FileCheck
> -check-prefix=CHECK-V6K-THUMB %s
>  // RUN: %clang -target arm -march=armv6k -mthumb -### -c %s 2>&1 |
> FileCheck -check-prefix=CHECK-V6K-THUMB %s
> -// CHECK-V6K-THUMB: "-cc1"{{.*}} "-triple" "thumbv6k-{{.*}} "-target-cpu"
> "arm1176jzf-s"
> +// CHECK-V6K-THUMB: "-cc1"{{.*}} "-triple" "thumbv6k-{{.*}} "-target-cpu"
> "arm1176j-s"
>
>  // RUN: %clang -target armv6t2 -### -c %s 2>&1 | FileCheck
> -check-prefix=CHECK-V6T2 %s
>  // RUN: %clang -target arm -march=armv6t2 -### -c %s 2>&1 | FileCheck
> -check-prefix=CHECK-V6T2 %s
> @@ -249,12 +249,14 @@
>  // RUN: %clang -target arm-linux-gnueabi -mcpu=arm1136jf-s -### -c %s
> 2>&1 | FileCheck -check-prefix=CHECK-CPUV6 %s
>  // CHECK-CPUV6: "-cc1"{{.*}} "-triple" "armv6-{{.*}}
>
> -// RUN: %clang -target arm-linux-gnueabi -mcpu=arm1176jz-s -### -c %s
> 2>&1 | FileCheck -check-prefix=CHECK-CPUV6K %s
> -// RUN: %clang -target arm-linux-gnueabi -mcpu=arm1176jzf-s -### -c %s
> 2>&1 | FileCheck -check-prefix=CHECK-CPUV6K %s
>  // RUN: %clang -target arm-linux-gnueabi -mcpu=mpcore -### -c %s 2>&1 |
> FileCheck -check-prefix=CHECK-CPUV6K %s
>  // RUN: %clang -target arm-linux-gnueabi -mcpu=mpcorenovfp -### -c %s
> 2>&1 | FileCheck -check-prefix=CHECK-CPUV6K %s
>  // CHECK-CPUV6K: "-cc1"{{.*}} "-triple" "armv6k-{{.*}}
>
> +// RUN: %clang -target arm-linux-gnueabi -mcpu=arm1176jz-s -### -c %s
> 2>&1 | FileCheck -check-prefix=CHECK-CPUV6KZ %s
> +// RUN: %clang -target arm-linux-gnueabi -mcpu=arm1176jzf-s -### -c %s
> 2>&1 | FileCheck -check-prefix=CHECK-CPUV6KZ %s
> +// CHECK-CPUV6KZ: "-cc1"{{.*}} "-triple" "armv6kz-{{.*}}
> +
>  // RUN: %clang -target arm-linux-gnueabi -mcpu=arm1156t2-s -### -c %s
> 2>&1 | FileCheck -check-prefix=CHECK-CPUV6T2 %s
>  // RUN: %clang -target arm-linux-gnueabi -mcpu=arm1156t2f-s -### -c %s
> 2>&1 | FileCheck -check-prefix=CHECK-CPUV6T2 %s
>  // CHECK-CPUV6T2: "-cc1"{{.*}} "-triple" "armv6t2-{{.*}}
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r248154 - [ARM] Handle +t2dsp feature as an ArchExtKind in ARMTargetParser.def

[James Molloy via cfe-commits]

Hi Artyom,

I have reverted this in r248173 because the pre-commmit review was not
completed.

Cheers,

James

On Mon, 21 Sep 2015 at 06:20 Artyom Skrobov via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: askrobov
> Date: Mon Sep 21 08:19:25 2015
> New Revision: 248154
>
> URL: http://llvm.org/viewvc/llvm-project?rev=248154=rev
> Log:
> [ARM] Handle +t2dsp feature as an ArchExtKind in ARMTargetParser.def
>
> Currently, the availability of DSP instructions (ACLE 6.4.7) is handled in
> a hand-rolled tricky condition block in lib/Basic/Targets.cpp, with a
> FIXME:
> attached.
>
> http://reviews.llvm.org/D12937 moved the handling of +t2dsp over to
> ARMTargetParser.def in LLVM, to be in line with other architecture
> extensions.
>
> This is the corresponding patch to clang, to clear the FIXME: and update
> the tests.
>
> Differential Revision: http://reviews.llvm.org/D12938
>
>
> Modified:
> cfe/trunk/lib/Basic/Targets.cpp
> cfe/trunk/test/CodeGen/arm-target-features.c
>
> Modified: cfe/trunk/lib/Basic/Targets.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=248154=248153=248154=diff
>
> ==
> --- cfe/trunk/lib/Basic/Targets.cpp (original)
> +++ cfe/trunk/lib/Basic/Targets.cpp Mon Sep 21 08:19:25 2015
> @@ -4121,6 +4121,7 @@ class ARMTargetInfo : public TargetInfo
>
>unsigned CRC : 1;
>unsigned Crypto : 1;
> +  unsigned T2DSP : 1;
>unsigned Unaligned : 1;
>
>enum {
> @@ -4472,6 +4473,7 @@ public:
>  FPU = 0;
>  CRC = 0;
>  Crypto = 0;
> +T2DSP = 0;
>  Unaligned = 1;
>  SoftFloat = SoftFloatABI = false;
>  HWDiv = 0;
> @@ -4507,6 +4509,8 @@ public:
>  CRC = 1;
>} else if (Feature == "+crypto") {
>  Crypto = 1;
> +  } else if (Feature == "+t2dsp") {
> +T2DSP = 1;
>} else if (Feature == "+fp-only-sp") {
>  HW_FP_remove |= HW_FP_DP | HW_FP_HP;
>} else if (Feature == "+strict-align") {
> @@ -4743,11 +4747,7 @@ public:
>
>  // ACLE 6.4.7 DSP instructions
>  bool hasDSP = false;
> -bool is5EOrAbove = (ArchVersion >= 6 ||
> -   (ArchVersion == 5 && CPUAttr.count('E')));
> -// FIXME: We are not getting all 32-bit ARM architectures
> -bool is32Bit = (!isThumb() || supportsThumb2());
> -if (is5EOrAbove && is32Bit && (CPUProfile != "M" || CPUAttr  ==
> "7EM")) {
> +if (T2DSP) {
>Builder.defineMacro("__ARM_FEATURE_DSP", "1");
>hasDSP = true;
>  }
>
> Modified: cfe/trunk/test/CodeGen/arm-target-features.c
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/arm-target-features.c?rev=248154=248153=248154=diff
>
> ==
> --- cfe/trunk/test/CodeGen/arm-target-features.c (original)
> +++ cfe/trunk/test/CodeGen/arm-target-features.c Mon Sep 21 08:19:25 2015
> @@ -1,15 +1,15 @@
>  // REQUIRES: arm-registered-target
>
>  // RUN: %clang_cc1 -triple thumbv7-linux-gnueabihf -target-cpu cortex-a8
> -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP3
> -// CHECK-VFP3: "target-features"="+neon,+vfp3"
> +// CHECK-VFP3: "target-features"="+neon,+t2dsp,+vfp3"
>
>
>  // RUN: %clang_cc1 -triple thumbv7-linux-gnueabi -target-cpu cortex-a9
> -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP3-FP16
> -// CHECK-VFP3-FP16: "target-features"="+fp16,+neon,+vfp3"
> +// CHECK-VFP3-FP16: "target-features"="+fp16,+neon,+t2dsp,+vfp3"
>
>
>  // RUN: %clang_cc1 -triple thumbv7-linux-gnueabihf -target-cpu cortex-a5
> -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4
> -// CHECK-VFP4: "target-features"="+neon,+vfp4"
> +// CHECK-VFP4: "target-features"="+neon,+t2dsp,+vfp4"
>
>
>  // RUN: %clang_cc1 -triple thumbv7-linux-gnueabihf -target-cpu cortex-a7
> -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4-DIV
> @@ -18,39 +18,41 @@
>  // RUN: %clang_cc1 -triple armv7-linux-gnueabihf -target-cpu cortex-a17
> -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4-DIV
>  // RUN: %clang_cc1 -triple thumbv7s-linux-gnueabi -target-cpu swift
> -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4-DIV
>  // RUN: %clang_cc1 -triple thumbv7-linux-gnueabihf -target-cpu krait
> -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4-DIV
> -// CHECK-VFP4-DIV: "target-features"="+hwdiv,+hwdiv-arm,+neon,+vfp4"
> +// CHECK-VFP4-DIV:
> "target-features"="+hwdiv,+hwdiv-arm,+neon,+t2dsp,+vfp4"
>
>
>  // RUN: %clang_cc1 -triple thumbv7s-apple-ios7.0 -target-cpu cyclone
> -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-BASIC-V8
>  // RUN: %clang_cc1 -triple armv8-linux-gnueabi -target-cpu cortex-a53
> -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-BASIC-V8
>  // RUN: %clang_cc1 -triple thumbv8-linux-gnueabihf -target-cpu cortex-a57
> -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-BASIC-V8
>  // RUN: %clang_cc1 -triple 

Re: [PATCH] D12938: [ARM] Handle +t2dsp feature as an ArchExtKind in ARMTargetParser.def

[James Molloy via cfe-commits]

Hi Artyom,

This, too, looks to be unreviewed. Could you please explain what's going on
here?


James
On Mon, 21 Sep 2015 at 06:21, Phabricator via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> This revision was automatically updated to reflect the committed changes.
> Closed by commit rL248154: [ARM] Handle +t2dsp feature as an ArchExtKind
> in ARMTargetParser.def (authored by askrobov).
>
> Changed prior to commit:
>   http://reviews.llvm.org/D12938?vs=35001=35244#toc
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D12938
>
> Files:
>   cfe/trunk/lib/Basic/Targets.cpp
>   cfe/trunk/test/CodeGen/arm-target-features.c
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D10414: Attach function attribute "arm-restrict-it" instead of passing arm-restrict-it as a backend-option

[James Molloy via cfe-commits]

jmolloy added a subscriber: jmolloy.
jmolloy added a comment.

Hi Akira,

I'm sorry to be contrary (and I missed the discussion on Tuesday because I was 
away on vacation) but I think there *is* a usecase for -mno-restrict-it to 
work, and I would hate to see it broken.

Non-restricted IT blocks are indeed deprecated for ARMv8 in the ARMARM. But 
there are circumstances where you may still want to emit them - the biggest 
example being you're compiling for a CPU microarchitecture that you *know* 
doesn't have a performance penalty on non-restricted IT blocks. Restricted IT 
blocks can pessimize code quite badly in some circumstances, and allowing 
people to turn it off for their target if needed is very important, IMO.

Cheers,

James


http://reviews.llvm.org/D10414



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

Re: [PATCH] D10414: Attach function attribute "arm-restrict-it" instead of passing arm-restrict-it as a backend-option

[James Molloy via cfe-commits]

jmolloy added a comment.

Hi Jim,

In an ideal world, yes. However there's no guarantee that all ARM implementors 
will (a) be able to commit to LLVM or (b) use ToT. Perhaps they're building a 
project that uses clang, or a specific version of clang, and this tuning option 
makes things go faster on their architecture.

I'm not arguing about the defaults, just about the breakage of -mno-restrict-it.

Cheers,

James


http://reviews.llvm.org/D10414



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

Re: [PATCH] D12148: [ARM] Allow passing/returning of __fp16 arguments

[James Molloy via cfe-commits]

jmolloy added a comment.

This looks alright to me, but I'd like to wait for someone more familiar with 
Clang to approve it.


http://reviews.llvm.org/D12148



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

Re: [PATCH] D12148: [ARM] Allow passing/returning of __fp16 arguments

[James Molloy via cfe-commits]

jmolloy added a subscriber: jmolloy.


Comment at: lib/CodeGen/TargetInfo.cpp:4717
@@ -4716,1 +4716,3 @@
 
+  // __fp16 gets passed as if it were an int or float, but with the top 32 bits
+  // unspecified.

Top 16 bits?


Comment at: lib/CodeGen/TargetInfo.cpp:4884
@@ -4874,1 +4883,3 @@
 
+  // __fp16 gets returned as if it were an int or float, but with the top 32
+  // bits unspecified.

Top 16 bits ?


Repository:
  rL LLVM

http://reviews.llvm.org/D12148



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