[PATCH] D72547: [llvm] Make new pass manager's OptimizationLevel a class

2020-01-15 Thread Teresa Johnson via Phabricator via cfe-commits
tejohnson accepted this revision.
tejohnson added a comment.
This revision is now accepted and ready to land.

LGTM

One thing to consider changing/removing in the summary is this comment:
"For example, (enum) "Level > 1" captures not only O2 
 and O3 
, but also Os, and Oz."
since that is actually correct (Os/Oz should be included in Level>1 as they are 
O2 ).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72547



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


[PATCH] D72820: Add pragma FP_CONTRACT support.

2020-01-15 Thread Pengfei Wang via Phabricator via cfe-commits
pengfei updated this revision to Diff 238417.
pengfei marked an inline comment as done.
pengfei added a comment.

Address review comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72820

Files:
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/test/CodeGen/constrained-math-builtins.c
  llvm/docs/LangRef.rst
  llvm/include/llvm/CodeGen/BasicTTIImpl.h
  llvm/include/llvm/CodeGen/ISDOpcodes.h
  llvm/include/llvm/IR/ConstrainedOps.def
  llvm/include/llvm/IR/Intrinsics.td
  llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
  llvm/test/CodeGen/X86/fp-intrinsics-fma.ll

Index: llvm/test/CodeGen/X86/fp-intrinsics-fma.ll
===
--- llvm/test/CodeGen/X86/fp-intrinsics-fma.ll
+++ llvm/test/CodeGen/X86/fp-intrinsics-fma.ll
@@ -3,6 +3,104 @@
 ; RUN: llc -O3 -mtriple=x86_64-pc-linux -mattr=+fma < %s | FileCheck %s --check-prefixes=COMMON,FMA
 ; RUN: llc -O3 -mtriple=x86_64-pc-linux -mattr=+avx512f < %s | FileCheck %s --check-prefixes=COMMON,FMA
 
+; Verify constrained fmul and fadd aren't fused.
+define float @f11(float %0, float %1, float %2) #0 {
+; NOFMA-LABEL: f11:
+; NOFMA:   # %bb.0: # %entry
+; NOFMA-NEXT:mulss %xmm1, %xmm0
+; NOFMA-NEXT:addss %xmm2, %xmm0
+; NOFMA-NEXT:retq
+;
+; FMA-LABEL: f11:
+; FMA:   # %bb.0: # %entry
+; FMA-NEXT:vmulss %xmm1, %xmm0, %xmm0
+; FMA-NEXT:vaddss %xmm2, %xmm0, %xmm0
+; FMA-NEXT:retq
+entry:
+  %3 = call float @llvm.experimental.constrained.fmul.f32(float %0, float %1,
+  metadata !"round.dynamic",
+  metadata !"fpexcept.strict") #0
+  %4 = call float @llvm.experimental.constrained.fadd.f32(float %3, float %2,
+  metadata !"round.dynamic",
+  metadata !"fpexcept.strict") #0
+  ret float %4
+}
+
+; Verify constrained fmul and fadd aren't fused.
+define double @f12(double %0, double %1, double %2) #0 {
+; NOFMA-LABEL: f12:
+; NOFMA:   # %bb.0: # %entry
+; NOFMA-NEXT:mulsd %xmm1, %xmm0
+; NOFMA-NEXT:addsd %xmm2, %xmm0
+; NOFMA-NEXT:retq
+;
+; FMA-LABEL: f12:
+; FMA:   # %bb.0: # %entry
+; FMA-NEXT:vmulsd %xmm1, %xmm0, %xmm0
+; FMA-NEXT:vaddsd %xmm2, %xmm0, %xmm0
+; FMA-NEXT:retq
+entry:
+  %3 = call double @llvm.experimental.constrained.fmul.f64(double %0, double %1,
+   metadata !"round.dynamic",
+   metadata !"fpexcept.strict") #0
+  %4 = call double @llvm.experimental.constrained.fadd.f64(double %3, double %2,
+   metadata !"round.dynamic",
+   metadata !"fpexcept.strict") #0
+  ret double %4
+}
+
+; Verify that fmuladd(3.5) isn't simplified when the rounding mode is
+; unknown.
+define float @f15() #0 {
+; NOFMA-LABEL: f15:
+; NOFMA:   # %bb.0: # %entry
+; NOFMA-NEXT:movss {{.*#+}} xmm1 = mem[0],zero,zero,zero
+; NOFMA-NEXT:movaps %xmm1, %xmm0
+; NOFMA-NEXT:mulss %xmm1, %xmm0
+; NOFMA-NEXT:addss %xmm1, %xmm0
+; NOFMA-NEXT:retq
+;
+; FMA-LABEL: f15:
+; FMA:   # %bb.0: # %entry
+; FMA-NEXT:vmovss {{.*#+}} xmm0 = mem[0],zero,zero,zero
+; FMA-NEXT:vfmadd213ss {{.*#+}} xmm0 = (xmm0 * xmm0) + xmm0
+; FMA-NEXT:retq
+entry:
+  %result = call float @llvm.experimental.constrained.fmuladd.f32(
+   float 3.5,
+   float 3.5,
+   float 3.5,
+   metadata !"round.dynamic",
+   metadata !"fpexcept.strict") #0
+  ret float %result
+}
+
+; Verify that fmuladd(42.1) isn't simplified when the rounding mode is
+; unknown.
+define double @f16() #0 {
+; NOFMA-LABEL: f16:
+; NOFMA:   # %bb.0: # %entry
+; NOFMA-NEXT:movsd {{.*#+}} xmm1 = mem[0],zero
+; NOFMA-NEXT:movapd %xmm1, %xmm0
+; NOFMA-NEXT:mulsd %xmm1, %xmm0
+; NOFMA-NEXT:addsd %xmm1, %xmm0
+; NOFMA-NEXT:retq
+;
+; FMA-LABEL: f16:
+; FMA:   # %bb.0: # %entry
+; FMA-NEXT:vmovsd {{.*#+}} xmm0 = mem[0],zero
+; FMA-NEXT:vfmadd213sd {{.*#+}} xmm0 = (xmm0 * xmm0) + xmm0
+; FMA-NEXT:retq
+entry:
+  %result = call double @llvm.experimental.constrained.fmuladd.f64(
+   double 42.1,
+   double 42.1,
+   double 42.1,
+   metadata !"round.dynamic",
+   metadata !"fpexcept.strict") #0
+  ret double 

[PATCH] D72824: [X86] Add combination for fma and fneg on X86 under strict FP.

2020-01-15 Thread Pengfei Wang via Phabricator via cfe-commits
pengfei created this revision.
pengfei added reviewers: craig.topper, andrew.w.kaylor, uweigand, RKSimon, 
LiuChen3.
pengfei added a project: LLVM.

X86 has instructions to calculate fma and fneg at the same time. But we combine 
the fneg and fma only when fneg is the source operand under strict FP.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D72824

Files:
  llvm/lib/Target/X86/X86ISelLowering.cpp
  llvm/lib/Target/X86/X86ISelLowering.h
  llvm/lib/Target/X86/X86InstrAVX512.td
  llvm/lib/Target/X86/X86InstrFMA.td
  llvm/lib/Target/X86/X86InstrFragmentsSIMD.td
  llvm/test/CodeGen/X86/fp-intrinsics-fma.ll

Index: llvm/test/CodeGen/X86/fp-intrinsics-fma.ll
===
--- llvm/test/CodeGen/X86/fp-intrinsics-fma.ll
+++ llvm/test/CodeGen/X86/fp-intrinsics-fma.ll
@@ -1,7 +1,271 @@
 ; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
 ; RUN: llc -O3 -mtriple=x86_64-pc-linux < %s | FileCheck %s --check-prefixes=COMMON,NOFMA
-; RUN: llc -O3 -mtriple=x86_64-pc-linux -mattr=+fma < %s | FileCheck %s --check-prefixes=COMMON,FMA
-; RUN: llc -O3 -mtriple=x86_64-pc-linux -mattr=+avx512f < %s | FileCheck %s --check-prefixes=COMMON,FMA
+; RUN: llc -O3 -mtriple=x86_64-pc-linux -mattr=+fma < %s | FileCheck %s --check-prefixes=COMMON,FMA,FMA-AVX1
+; RUN: llc -O3 -mtriple=x86_64-pc-linux -mattr=+avx512f < %s | FileCheck %s --check-prefixes=COMMON,FMA,FMA-AVX512
+
+define float @f1(float %0, float %1, float %2) #0 {
+; NOFMA-LABEL: f1:
+; NOFMA:   # %bb.0: # %entry
+; NOFMA-NEXT:pushq %rax
+; NOFMA-NEXT:.cfi_def_cfa_offset 16
+; NOFMA-NEXT:xorps {{.*}}(%rip), %xmm0
+; NOFMA-NEXT:callq fmaf
+; NOFMA-NEXT:popq %rax
+; NOFMA-NEXT:.cfi_def_cfa_offset 8
+; NOFMA-NEXT:retq
+;
+; FMA-LABEL: f1:
+; FMA:   # %bb.0: # %entry
+; FMA-NEXT:vfnmadd213ss {{.*#+}} xmm0 = -(xmm1 * xmm0) + xmm2
+; FMA-NEXT:retq
+entry:
+  %3 = fneg float %0
+  %result = call float @llvm.experimental.constrained.fma.f32(float %3, float %1, float %2,
+  metadata !"round.dynamic",
+  metadata !"fpexcept.strict") #0
+  ret float %result
+}
+
+define double @f2(double %0, double %1, double %2) #0 {
+; NOFMA-LABEL: f2:
+; NOFMA:   # %bb.0: # %entry
+; NOFMA-NEXT:pushq %rax
+; NOFMA-NEXT:.cfi_def_cfa_offset 16
+; NOFMA-NEXT:xorps {{.*}}(%rip), %xmm0
+; NOFMA-NEXT:callq fma
+; NOFMA-NEXT:popq %rax
+; NOFMA-NEXT:.cfi_def_cfa_offset 8
+; NOFMA-NEXT:retq
+;
+; FMA-LABEL: f2:
+; FMA:   # %bb.0: # %entry
+; FMA-NEXT:vfnmadd213sd {{.*#+}} xmm0 = -(xmm1 * xmm0) + xmm2
+; FMA-NEXT:retq
+entry:
+  %3 = fneg double %0
+  %result = call double @llvm.experimental.constrained.fma.f64(double %3, double %1, double %2,
+   metadata !"round.dynamic",
+   metadata !"fpexcept.strict") #0
+  ret double %result
+}
+
+define float @f3(float %0, float %1, float %2) #0 {
+; NOFMA-LABEL: f3:
+; NOFMA:   # %bb.0: # %entry
+; NOFMA-NEXT:pushq %rax
+; NOFMA-NEXT:.cfi_def_cfa_offset 16
+; NOFMA-NEXT:xorps {{.*}}(%rip), %xmm2
+; NOFMA-NEXT:callq fmaf
+; NOFMA-NEXT:popq %rax
+; NOFMA-NEXT:.cfi_def_cfa_offset 8
+; NOFMA-NEXT:retq
+;
+; FMA-LABEL: f3:
+; FMA:   # %bb.0: # %entry
+; FMA-NEXT:vfmsub213ss {{.*#+}} xmm0 = (xmm1 * xmm0) - xmm2
+; FMA-NEXT:retq
+entry:
+  %3 = fneg float %2
+  %result = call float @llvm.experimental.constrained.fma.f32(float %0, float %1, float %3,
+  metadata !"round.dynamic",
+  metadata !"fpexcept.strict") #0
+  ret float %result
+}
+
+define double @f4(double %0, double %1, double %2) #0 {
+; NOFMA-LABEL: f4:
+; NOFMA:   # %bb.0: # %entry
+; NOFMA-NEXT:pushq %rax
+; NOFMA-NEXT:.cfi_def_cfa_offset 16
+; NOFMA-NEXT:xorps {{.*}}(%rip), %xmm2
+; NOFMA-NEXT:callq fma
+; NOFMA-NEXT:popq %rax
+; NOFMA-NEXT:.cfi_def_cfa_offset 8
+; NOFMA-NEXT:retq
+;
+; FMA-LABEL: f4:
+; FMA:   # %bb.0: # %entry
+; FMA-NEXT:vfmsub213sd {{.*#+}} xmm0 = (xmm1 * xmm0) - xmm2
+; FMA-NEXT:retq
+entry:
+  %3 = fneg double %2
+  %result = call double @llvm.experimental.constrained.fma.f64(double %0, double %1, double %3,
+   metadata !"round.dynamic",
+   metadata !"fpexcept.strict") #0
+  ret double %result
+}
+
+define float @f5(float %0, float %1, float %2) #0 {
+; NOFMA-LABEL: f5:
+; NOFMA:   # %bb.0: # %entry
+; NOFMA-NEXT:pushq %rax
+; NOFMA-NEXT:.cfi_def_cfa_offset 16
+; NOFMA-NEXT:movaps {{.*#+}} xmm3 = 

[PATCH] D72820: Add pragma FP_CONTRACT support.

2020-01-15 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added inline comments.



Comment at: llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:7061
 
+  auto pushOutChain = [this](auto , auto EB) {
+assert(Result.getNode()->getNumValues() == 2);

Why is Result a reference? It's not modified is it? Don't use auto for 
parameter types. llvm coding style prefers auto to only be used when the type 
is easily assumed by someone reading the code.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72820



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


[PATCH] D72820: Add pragma FP_CONTRACT support.

2020-01-15 Thread Pengfei Wang via Phabricator via cfe-commits
pengfei updated this revision to Diff 238414.
pengfei marked an inline comment as done.
pengfei added a comment.

Address review comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72820

Files:
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/test/CodeGen/constrained-math-builtins.c
  llvm/docs/LangRef.rst
  llvm/include/llvm/CodeGen/BasicTTIImpl.h
  llvm/include/llvm/CodeGen/ISDOpcodes.h
  llvm/include/llvm/IR/ConstrainedOps.def
  llvm/include/llvm/IR/Intrinsics.td
  llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
  llvm/test/CodeGen/X86/fp-intrinsics-fma.ll

Index: llvm/test/CodeGen/X86/fp-intrinsics-fma.ll
===
--- llvm/test/CodeGen/X86/fp-intrinsics-fma.ll
+++ llvm/test/CodeGen/X86/fp-intrinsics-fma.ll
@@ -3,6 +3,104 @@
 ; RUN: llc -O3 -mtriple=x86_64-pc-linux -mattr=+fma < %s | FileCheck %s --check-prefixes=COMMON,FMA
 ; RUN: llc -O3 -mtriple=x86_64-pc-linux -mattr=+avx512f < %s | FileCheck %s --check-prefixes=COMMON,FMA
 
+; Verify constrained fmul and fadd aren't fused.
+define float @f11(float %0, float %1, float %2) #0 {
+; NOFMA-LABEL: f11:
+; NOFMA:   # %bb.0: # %entry
+; NOFMA-NEXT:mulss %xmm1, %xmm0
+; NOFMA-NEXT:addss %xmm2, %xmm0
+; NOFMA-NEXT:retq
+;
+; FMA-LABEL: f11:
+; FMA:   # %bb.0: # %entry
+; FMA-NEXT:vmulss %xmm1, %xmm0, %xmm0
+; FMA-NEXT:vaddss %xmm2, %xmm0, %xmm0
+; FMA-NEXT:retq
+entry:
+  %3 = call float @llvm.experimental.constrained.fmul.f32(float %0, float %1,
+  metadata !"round.dynamic",
+  metadata !"fpexcept.strict") #0
+  %4 = call float @llvm.experimental.constrained.fadd.f32(float %3, float %2,
+  metadata !"round.dynamic",
+  metadata !"fpexcept.strict") #0
+  ret float %4
+}
+
+; Verify constrained fmul and fadd aren't fused.
+define double @f12(double %0, double %1, double %2) #0 {
+; NOFMA-LABEL: f12:
+; NOFMA:   # %bb.0: # %entry
+; NOFMA-NEXT:mulsd %xmm1, %xmm0
+; NOFMA-NEXT:addsd %xmm2, %xmm0
+; NOFMA-NEXT:retq
+;
+; FMA-LABEL: f12:
+; FMA:   # %bb.0: # %entry
+; FMA-NEXT:vmulsd %xmm1, %xmm0, %xmm0
+; FMA-NEXT:vaddsd %xmm2, %xmm0, %xmm0
+; FMA-NEXT:retq
+entry:
+  %3 = call double @llvm.experimental.constrained.fmul.f64(double %0, double %1,
+   metadata !"round.dynamic",
+   metadata !"fpexcept.strict") #0
+  %4 = call double @llvm.experimental.constrained.fadd.f64(double %3, double %2,
+   metadata !"round.dynamic",
+   metadata !"fpexcept.strict") #0
+  ret double %4
+}
+
+; Verify that fmuladd(3.5) isn't simplified when the rounding mode is
+; unknown.
+define float @f15() #0 {
+; NOFMA-LABEL: f15:
+; NOFMA:   # %bb.0: # %entry
+; NOFMA-NEXT:movss {{.*#+}} xmm1 = mem[0],zero,zero,zero
+; NOFMA-NEXT:movaps %xmm1, %xmm0
+; NOFMA-NEXT:mulss %xmm1, %xmm0
+; NOFMA-NEXT:addss %xmm1, %xmm0
+; NOFMA-NEXT:retq
+;
+; FMA-LABEL: f15:
+; FMA:   # %bb.0: # %entry
+; FMA-NEXT:vmovss {{.*#+}} xmm0 = mem[0],zero,zero,zero
+; FMA-NEXT:vfmadd213ss {{.*#+}} xmm0 = (xmm0 * xmm0) + xmm0
+; FMA-NEXT:retq
+entry:
+  %result = call float @llvm.experimental.constrained.fmuladd.f32(
+   float 3.5,
+   float 3.5,
+   float 3.5,
+   metadata !"round.dynamic",
+   metadata !"fpexcept.strict") #0
+  ret float %result
+}
+
+; Verify that fmuladd(42.1) isn't simplified when the rounding mode is
+; unknown.
+define double @f16() #0 {
+; NOFMA-LABEL: f16:
+; NOFMA:   # %bb.0: # %entry
+; NOFMA-NEXT:movsd {{.*#+}} xmm1 = mem[0],zero
+; NOFMA-NEXT:movapd %xmm1, %xmm0
+; NOFMA-NEXT:mulsd %xmm1, %xmm0
+; NOFMA-NEXT:addsd %xmm1, %xmm0
+; NOFMA-NEXT:retq
+;
+; FMA-LABEL: f16:
+; FMA:   # %bb.0: # %entry
+; FMA-NEXT:vmovsd {{.*#+}} xmm0 = mem[0],zero
+; FMA-NEXT:vfmadd213sd {{.*#+}} xmm0 = (xmm0 * xmm0) + xmm0
+; FMA-NEXT:retq
+entry:
+  %result = call double @llvm.experimental.constrained.fmuladd.f64(
+   double 42.1,
+   double 42.1,
+   double 42.1,
+   metadata !"round.dynamic",
+   metadata !"fpexcept.strict") #0
+  ret double 

[PATCH] D50360: [Concepts] Requires Expressions

2020-01-15 Thread Saar Raz via Phabricator via cfe-commits
saar.raz marked an inline comment as done.
saar.raz added a comment.

Addressed comments in latest diff.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D50360



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


[PATCH] D72820: Add pragma FP_CONTRACT support.

2020-01-15 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added inline comments.



Comment at: llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:7064
+
+  auto pushOutChain = [&]() {
+assert(Result.getNode()->getNumValues() == 2);

Can you make the SDValue Result an argument of this and only capture 'this'. I 
don't like depending on reassigning Result.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72820



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


[PATCH] D72820: Add pragma FP_CONTRACT support.

2020-01-15 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added a comment.

The title of this review is misleading.  It should at least mention FPEnv, 
constrained intrinsics, or strict fp or something. Right now it sounds like 
FP_CONTRACT isn't supported at all.

Can we split most of the X86 changes into a separate patch? Most of it can be 
tested with fneg and constrained.fma.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72820



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


[PATCH] D52193: RFC: [clang] Multithreaded compilation support -- NOT FOR SUBMIT

2020-01-15 Thread Alexandre Ganea via Phabricator via cfe-commits
aganea added a comment.

Hi @tycho ! Sorry for not getting back earlier.
I implemented an alternate approach last year, which proved to be better (in 
terms of build times) than what I proposed in this demo patch. That is, using a 
thread pool instead of the process pool as implemented here. This makes 
compilation with /MP considerably faster, and allows for neat optimizations 
like file caching, re-using allocated memory pages, and possibly other things 
down the line. But before getting there, it requires somehow making `cl::opt` 
and the `CommandLineParser` thread-safe, thus revive this RFC thread 
. In 
essence, we want a mode where `cl::opt`s have their data optionally stored in a 
stack context, so that we can safely call a CC1Command 

 in each thread. I'll write a proposal to revive the RFC.


Repository:
  rC Clang

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

https://reviews.llvm.org/D52193



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


[PATCH] D72820: Add pragma FP_CONTRACT support.

2020-01-15 Thread Pengfei Wang via Phabricator via cfe-commits
pengfei updated this revision to Diff 238408.
pengfei added a comment.

Remove dead code.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72820

Files:
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/test/CodeGen/constrained-math-builtins.c
  llvm/docs/LangRef.rst
  llvm/include/llvm/CodeGen/BasicTTIImpl.h
  llvm/include/llvm/CodeGen/ISDOpcodes.h
  llvm/include/llvm/IR/ConstrainedOps.def
  llvm/include/llvm/IR/Intrinsics.td
  llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
  llvm/lib/Target/X86/X86ISelLowering.cpp
  llvm/lib/Target/X86/X86ISelLowering.h
  llvm/lib/Target/X86/X86InstrAVX512.td
  llvm/lib/Target/X86/X86InstrFMA.td
  llvm/lib/Target/X86/X86InstrFragmentsSIMD.td
  llvm/test/CodeGen/X86/fp-intrinsics-fma.ll

Index: llvm/test/CodeGen/X86/fp-intrinsics-fma.ll
===
--- llvm/test/CodeGen/X86/fp-intrinsics-fma.ll
+++ llvm/test/CodeGen/X86/fp-intrinsics-fma.ll
@@ -1,7 +1,339 @@
 ; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
 ; RUN: llc -O3 -mtriple=x86_64-pc-linux < %s | FileCheck %s --check-prefixes=COMMON,NOFMA
-; RUN: llc -O3 -mtriple=x86_64-pc-linux -mattr=+fma < %s | FileCheck %s --check-prefixes=COMMON,FMA
-; RUN: llc -O3 -mtriple=x86_64-pc-linux -mattr=+avx512f < %s | FileCheck %s --check-prefixes=COMMON,FMA
+; RUN: llc -O3 -mtriple=x86_64-pc-linux -mattr=+fma < %s | FileCheck %s --check-prefixes=COMMON,FMA,FMA-AVX1
+; RUN: llc -O3 -mtriple=x86_64-pc-linux -mattr=+avx512f < %s | FileCheck %s --check-prefixes=COMMON,FMA,FMA-AVX512
+
+define float @f1(float %0, float %1, float %2) #0 {
+; NOFMA-LABEL: f1:
+; NOFMA:   # %bb.0: # %entry
+; NOFMA-NEXT:xorps {{.*}}(%rip), %xmm0
+; NOFMA-NEXT:mulss %xmm1, %xmm0
+; NOFMA-NEXT:addss %xmm2, %xmm0
+; NOFMA-NEXT:retq
+;
+; FMA-LABEL: f1:
+; FMA:   # %bb.0: # %entry
+; FMA-NEXT:vfnmadd213ss {{.*#+}} xmm0 = -(xmm1 * xmm0) + xmm2
+; FMA-NEXT:retq
+entry:
+  %3 = fneg float %0
+  %result = call float @llvm.experimental.constrained.fmuladd.f32(float %3, float %1, float %2,
+  metadata !"round.dynamic",
+  metadata !"fpexcept.strict") #0
+  ret float %result
+}
+
+define double @f2(double %0, double %1, double %2) #0 {
+; NOFMA-LABEL: f2:
+; NOFMA:   # %bb.0: # %entry
+; NOFMA-NEXT:xorpd {{.*}}(%rip), %xmm0
+; NOFMA-NEXT:mulsd %xmm1, %xmm0
+; NOFMA-NEXT:addsd %xmm2, %xmm0
+; NOFMA-NEXT:retq
+;
+; FMA-LABEL: f2:
+; FMA:   # %bb.0: # %entry
+; FMA-NEXT:vfnmadd213sd {{.*#+}} xmm0 = -(xmm1 * xmm0) + xmm2
+; FMA-NEXT:retq
+entry:
+  %3 = fneg double %0
+  %result = call double @llvm.experimental.constrained.fmuladd.f64(double %3, double %1, double %2,
+   metadata !"round.dynamic",
+   metadata !"fpexcept.strict") #0
+  ret double %result
+}
+
+define float @f3(float %0, float %1, float %2) #0 {
+; NOFMA-LABEL: f3:
+; NOFMA:   # %bb.0: # %entry
+; NOFMA-NEXT:xorps {{.*}}(%rip), %xmm2
+; NOFMA-NEXT:mulss %xmm1, %xmm0
+; NOFMA-NEXT:addss %xmm2, %xmm0
+; NOFMA-NEXT:retq
+;
+; FMA-LABEL: f3:
+; FMA:   # %bb.0: # %entry
+; FMA-NEXT:vfmsub213ss {{.*#+}} xmm0 = (xmm1 * xmm0) - xmm2
+; FMA-NEXT:retq
+entry:
+  %3 = fneg float %2
+  %result = call float @llvm.experimental.constrained.fmuladd.f32(float %0, float %1, float %3,
+  metadata !"round.dynamic",
+  metadata !"fpexcept.strict") #0
+  ret float %result
+}
+
+define double @f4(double %0, double %1, double %2) #0 {
+; NOFMA-LABEL: f4:
+; NOFMA:   # %bb.0: # %entry
+; NOFMA-NEXT:xorpd {{.*}}(%rip), %xmm2
+; NOFMA-NEXT:mulsd %xmm1, %xmm0
+; NOFMA-NEXT:addsd %xmm2, %xmm0
+; NOFMA-NEXT:retq
+;
+; FMA-LABEL: f4:
+; FMA:   # %bb.0: # %entry
+; FMA-NEXT:vfmsub213sd {{.*#+}} xmm0 = (xmm1 * xmm0) - xmm2
+; FMA-NEXT:retq
+entry:
+  %3 = fneg double %2
+  %result = call double @llvm.experimental.constrained.fmuladd.f64(double %0, double %1, double %3,
+   metadata !"round.dynamic",
+   metadata !"fpexcept.strict") #0
+  ret double %result
+}
+
+define float @f5(float %0, float %1, float %2) #0 {
+; NOFMA-LABEL: f5:
+; NOFMA:   # %bb.0: # %entry
+; NOFMA-NEXT:movaps {{.*#+}} xmm3 = [-0.0E+0,-0.0E+0,-0.0E+0,-0.0E+0]
+; NOFMA-NEXT:xorps %xmm3, %xmm0
+; NOFMA-NEXT:xorps %xmm3, %xmm2
+; NOFMA-NEXT:mulss %xmm1, %xmm0
+; NOFMA-NEXT:addss %xmm2, %xmm0
+; NOFMA-NEXT:retq
+;
+; FMA-LABEL: f5:
+; FMA:  

[PATCH] D65042: [Concept] Placeholder constraints and abbreviated templates

2020-01-15 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added a comment.

I think this might work out more cleanly if we represented a constrained auto 
type as a `ConstrainedType` node wrapping an `AutoType` node rather than 
putting both things into the same object. (This will become more pressing 
if/when C++ starts allowing, for example, constrained placeholders for deduced 
class template specializations, or constrained `typename` types, which are 
likely future directions.) But let's go with this approach for now.

I really like the unification of generic lambdas with abbreviated functions 
here.




Comment at: .gitignore:57-60
+<<< Updated upstream
+===
+clang/\.idea/
+>>> Stashed changes

Please revert this change =)



Comment at: clang/include/clang/AST/RecursiveASTVisitor.h:1297
+TRY_TO(TraverseNestedNameSpecifierLoc(TL.getNestedNameSpecifierLoc()));
+for (unsigned I = 0, E = TL.getNumArgs(); I != E; ++I)
+  TRY_TO(TraverseTemplateArgumentLoc(TL.getArgLoc(I)));

Should we traverse a `DeclarationNameInfo` for the concept name here? 
(Rewriting tools will want to know where the concept name was written.)



Comment at: clang/include/clang/Basic/DiagnosticParseKinds.td:1343
+def err_placeholder_missing_auto_after_type_constraint : Error<
+  "ISO C++2a requires 'auto' after a concept name for placeholders">;
+def err_placeholder_decltype_non_auto : Error<

We usually only use this "ISO C++xy requires [...]" formulation in diagnostics 
for something we support as a language extension (effectively, when 
distinguishing between "ISO C++ requires this" and "Clang requires this").



Comment at: clang/include/clang/Basic/DiagnosticParseKinds.td:1345-1346
+def err_placeholder_decltype_non_auto : Error<
+  "only 'decltype(auto)' or 'auto' may appear after a concept name for "
+  "placeholders">;
 }

I'm not sure what the "for placeholders" means in these diagnostics. Maybe just 
"expected 'auto' or 'decltype(auto)' after concept name"?



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:2612-2614
+def err_unsupported_placeholder_constraint : Error<
+  "constrained placeholder types other than simple 'auto' on non-type template 
"
+  "parameters not supported yet">;

"simple 'auto'" isn't a constrained placeholder type, so should this just say 
"constrained placeholder type as type of non-type template parameter not 
supported yet"?



Comment at: clang/include/clang/Sema/ScopeInfo.h:37
 #include "llvm/Support/ErrorHandling.h"
+#include "Sema.h"
 #include 

Please fully-qualify this file name ("clang/Sema/Sema.h") and order it with the 
other clang/Sema includes above.

That said... I think this is backwards from the layering I'd expect. How about 
this: move `InventedTemplateParameterInfo` into `DeclSpec.h`, and include that 
here.



Comment at: clang/lib/AST/ASTStructuralEquivalence.cpp:742
+  if (Auto1->getTypeConstraintConcept()
+  != Auto2->getTypeConstraintConcept())
+return false;

`!=` on the previous line, please.



Comment at: clang/lib/AST/ASTStructuralEquivalence.cpp:744-745
+return false;
+  auto Auto1Args = Auto1->getTypeConstraintArguments();
+  auto Auto2Args = Auto2->getTypeConstraintArguments();
+  if (Auto1Args.size() != Auto2Args.size())

Please don't use `auto` here; the type is not obvious from the context, and it 
matters (are we copying a vector here?).



Comment at: clang/lib/AST/DeclTemplate.cpp:165
+  } else if (const auto *NTTP = dyn_cast(Param)) {
+if (const auto *E = NTTP->getPlaceholderTypeConstraint())
+  AC.push_back(E);

Using `auto` rather than `Expr` here doesn't improve readability; please just 
spell out the type.



Comment at: clang/lib/AST/TypeLoc.cpp:681
+
+AutoTypeLoc TypeLoc::findAutoTypeLoc() const {
+  TypeLoc Res = GetContainedAutoTypeLocVisitor().Visit(*this);

Please name this consistently with the corresponding function on `Type` 
(`getContainedAutoTypeLoc`).



Comment at: clang/lib/Parse/ParseDecl.cpp:3197-3206
+  if (Next.is(tok::annot_template_id) &&
+  static_cast(Next.getAnnotationValue())
+->Kind == TNK_Concept_template &&
+  GetLookAheadToken(2).isOneOf(tok::kw_auto, tok::kw_decltype)) {
+// This is a qualified placeholder-specifier, e.g., ::C auto ...
+// Consume the scope annotation and continue to consume the template-id
+// as a placeholder-specifier.

This seems surprising. It looks like we're just throwing away the scope 
specifier in this case? (Should we be storing `SS` as `DS.getTypeSpecScope()` 
or similar?)



Comment at: clang/lib/Parse/ParseDecl.cpp:3462
+if 

[PATCH] D72820: Add pragma FP_CONTRACT support.

2020-01-15 Thread Pengfei Wang via Phabricator via cfe-commits
pengfei created this revision.
pengfei added reviewers: craig.topper, andrew.w.kaylor, uweigand, RKSimon, 
LiuChen3.
Herald added subscribers: llvm-commits, cfe-commits, jdoerfert, hiraditya.
Herald added projects: clang, LLVM.

Support pragma FP_CONTRACT.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D72820

Files:
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/test/CodeGen/constrained-math-builtins.c
  llvm/docs/LangRef.rst
  llvm/include/llvm/CodeGen/BasicTTIImpl.h
  llvm/include/llvm/CodeGen/ISDOpcodes.h
  llvm/include/llvm/IR/ConstrainedOps.def
  llvm/include/llvm/IR/Intrinsics.td
  llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
  llvm/lib/Target/X86/X86ISelLowering.cpp
  llvm/lib/Target/X86/X86ISelLowering.h
  llvm/lib/Target/X86/X86InstrAVX512.td
  llvm/lib/Target/X86/X86InstrFMA.td
  llvm/lib/Target/X86/X86InstrFragmentsSIMD.td
  llvm/test/CodeGen/X86/fp-intrinsics-fma.ll

Index: llvm/test/CodeGen/X86/fp-intrinsics-fma.ll
===
--- llvm/test/CodeGen/X86/fp-intrinsics-fma.ll
+++ llvm/test/CodeGen/X86/fp-intrinsics-fma.ll
@@ -1,7 +1,339 @@
 ; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
 ; RUN: llc -O3 -mtriple=x86_64-pc-linux < %s | FileCheck %s --check-prefixes=COMMON,NOFMA
-; RUN: llc -O3 -mtriple=x86_64-pc-linux -mattr=+fma < %s | FileCheck %s --check-prefixes=COMMON,FMA
-; RUN: llc -O3 -mtriple=x86_64-pc-linux -mattr=+avx512f < %s | FileCheck %s --check-prefixes=COMMON,FMA
+; RUN: llc -O3 -mtriple=x86_64-pc-linux -mattr=+fma < %s | FileCheck %s --check-prefixes=COMMON,FMA,FMA-AVX1
+; RUN: llc -O3 -mtriple=x86_64-pc-linux -mattr=+avx512f < %s | FileCheck %s --check-prefixes=COMMON,FMA,FMA-AVX512
+
+define float @f1(float %0, float %1, float %2) #0 {
+; NOFMA-LABEL: f1:
+; NOFMA:   # %bb.0: # %entry
+; NOFMA-NEXT:xorps {{.*}}(%rip), %xmm0
+; NOFMA-NEXT:mulss %xmm1, %xmm0
+; NOFMA-NEXT:addss %xmm2, %xmm0
+; NOFMA-NEXT:retq
+;
+; FMA-LABEL: f1:
+; FMA:   # %bb.0: # %entry
+; FMA-NEXT:vfnmadd213ss {{.*#+}} xmm0 = -(xmm1 * xmm0) + xmm2
+; FMA-NEXT:retq
+entry:
+  %3 = fneg float %0
+  %result = call float @llvm.experimental.constrained.fmuladd.f32(float %3, float %1, float %2,
+  metadata !"round.dynamic",
+  metadata !"fpexcept.strict") #0
+  ret float %result
+}
+
+define double @f2(double %0, double %1, double %2) #0 {
+; NOFMA-LABEL: f2:
+; NOFMA:   # %bb.0: # %entry
+; NOFMA-NEXT:xorpd {{.*}}(%rip), %xmm0
+; NOFMA-NEXT:mulsd %xmm1, %xmm0
+; NOFMA-NEXT:addsd %xmm2, %xmm0
+; NOFMA-NEXT:retq
+;
+; FMA-LABEL: f2:
+; FMA:   # %bb.0: # %entry
+; FMA-NEXT:vfnmadd213sd {{.*#+}} xmm0 = -(xmm1 * xmm0) + xmm2
+; FMA-NEXT:retq
+entry:
+  %3 = fneg double %0
+  %result = call double @llvm.experimental.constrained.fmuladd.f64(double %3, double %1, double %2,
+   metadata !"round.dynamic",
+   metadata !"fpexcept.strict") #0
+  ret double %result
+}
+
+define float @f3(float %0, float %1, float %2) #0 {
+; NOFMA-LABEL: f3:
+; NOFMA:   # %bb.0: # %entry
+; NOFMA-NEXT:xorps {{.*}}(%rip), %xmm2
+; NOFMA-NEXT:mulss %xmm1, %xmm0
+; NOFMA-NEXT:addss %xmm2, %xmm0
+; NOFMA-NEXT:retq
+;
+; FMA-LABEL: f3:
+; FMA:   # %bb.0: # %entry
+; FMA-NEXT:vfmsub213ss {{.*#+}} xmm0 = (xmm1 * xmm0) - xmm2
+; FMA-NEXT:retq
+entry:
+  %3 = fneg float %2
+  %result = call float @llvm.experimental.constrained.fmuladd.f32(float %0, float %1, float %3,
+  metadata !"round.dynamic",
+  metadata !"fpexcept.strict") #0
+  ret float %result
+}
+
+define double @f4(double %0, double %1, double %2) #0 {
+; NOFMA-LABEL: f4:
+; NOFMA:   # %bb.0: # %entry
+; NOFMA-NEXT:xorpd {{.*}}(%rip), %xmm2
+; NOFMA-NEXT:mulsd %xmm1, %xmm0
+; NOFMA-NEXT:addsd %xmm2, %xmm0
+; NOFMA-NEXT:retq
+;
+; FMA-LABEL: f4:
+; FMA:   # %bb.0: # %entry
+; FMA-NEXT:vfmsub213sd {{.*#+}} xmm0 = (xmm1 * xmm0) - xmm2
+; FMA-NEXT:retq
+entry:
+  %3 = fneg double %2
+  %result = call double @llvm.experimental.constrained.fmuladd.f64(double %0, double %1, double %3,
+   metadata !"round.dynamic",
+   metadata !"fpexcept.strict") #0
+  ret double %result
+}
+
+define float @f5(float %0, float %1, float %2) #0 {
+; NOFMA-LABEL: f5:
+; NOFMA:   # %bb.0: # %entry
+; NOFMA-NEXT:movaps {{.*#+}} xmm3 = [-0.0E+0,-0.0E+0,-0.0E+0,-0.0E+0]
+; NOFMA-NEXT:xorps %xmm3, %xmm0
+; NOFMA-NEXT:xorps %xmm3, %xmm2
+; NOFMA-NEXT:mulss 

Re: [clang] 45d7080 - PR42694 Support explicit(bool) in older language modes as an extension.

2020-01-15 Thread Richard Smith via cfe-commits
Hans, could this change be ported to the Clang 10 branch? In PR42694 the
MSVC stdlib developers requested that Clang support this because their
standard library will soon rely on it.

On Wed, 15 Jan 2020 at 18:50, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
> Author: Richard Smith
> Date: 2020-01-15T18:38:23-08:00
> New Revision: 45d70806f4386adfb62b0d75949a8aad58e0576f
>
> URL:
> https://github.com/llvm/llvm-project/commit/45d70806f4386adfb62b0d75949a8aad58e0576f
> DIFF:
> https://github.com/llvm/llvm-project/commit/45d70806f4386adfb62b0d75949a8aad58e0576f.diff
>
> LOG: PR42694 Support explicit(bool) in older language modes as an
> extension.
>
> This needs somewhat careful disambiguation, as C++2a explicit(bool) is a
> breaking change. We only enable it in cases where the source construct
> could not possibly be anything else.
>
> Added:
>
>
> Modified:
> clang/include/clang/Basic/DiagnosticParseKinds.td
> clang/include/clang/Parse/Parser.h
> clang/lib/Parse/ParseDecl.cpp
> clang/lib/Parse/ParseTentative.cpp
> clang/lib/Parse/Parser.cpp
> clang/test/SemaCXX/cxx2a-explicit-bool.cpp
>
> Removed:
>
>
>
>
> 
> diff  --git a/clang/include/clang/Basic/DiagnosticParseKinds.td
> b/clang/include/clang/Basic/DiagnosticParseKinds.td
> index cc6a74ac3e6d..41f788e7d9bd 100644
> --- a/clang/include/clang/Basic/DiagnosticParseKinds.td
> +++ b/clang/include/clang/Basic/DiagnosticParseKinds.td
> @@ -33,10 +33,6 @@ def err_asm_goto_cannot_have_output : Error<
>
>  let CategoryName = "Parse Issue" in {
>
> -def warn_cxx2a_compat_explicit_bool : Warning<
> -  "this expression will be parsed as explicit(bool) in C++2a">,
> -  InGroup, DefaultIgnore;
> -
>  def ext_empty_translation_unit : Extension<
>"ISO C requires a translation unit to contain at least one
> declaration">,
>InGroup>;
> @@ -684,6 +680,15 @@ def err_ms_property_expected_comma_or_rparen : Error<
>  def err_ms_property_initializer : Error<
>"property declaration cannot have an in-class initializer">;
>
> +def warn_cxx2a_compat_explicit_bool : Warning<
> +  "this expression will be parsed as explicit(bool) in C++2a">,
> +  InGroup, DefaultIgnore;
> +def warn_cxx17_compat_explicit_bool : Warning<
> +  "explicit(bool) is incompatible with C++ standards before C++2a">,
> +  InGroup, DefaultIgnore;
> +def ext_explicit_bool : ExtWarn<"explicit(bool) is a C++2a extension">,
> +  InGroup;
> +
>  /// C++ Templates
>  def err_expected_template : Error<"expected template">;
>  def err_unknown_template_name : Error<
>
> diff  --git a/clang/include/clang/Parse/Parser.h
> b/clang/include/clang/Parse/Parser.h
> index e320c9647818..b7bed4713992 100644
> --- a/clang/include/clang/Parse/Parser.h
> +++ b/clang/include/clang/Parse/Parser.h
> @@ -806,6 +806,16 @@ class Parser : public CodeCompletionHandler {
>   bool IsNewScope);
>bool TryAnnotateCXXScopeToken(bool EnteringContext = false);
>
> +  bool MightBeCXXScopeToken() {
> +return Tok.is(tok::identifier) || Tok.is(tok::coloncolon) ||
> +   (Tok.is(tok::annot_template_id) &&
> +NextToken().is(tok::coloncolon)) ||
> +   Tok.is(tok::kw_decltype) || Tok.is(tok::kw___super);
> +  }
> +  bool TryAnnotateOptionalCXXScopeToken(bool EnteringContext = false) {
> +return MightBeCXXScopeToken() &&
> TryAnnotateCXXScopeToken(EnteringContext);
> +  }
> +
>  private:
>enum AnnotatedNameKind {
>  /// Annotation has failed and emitted an error.
> @@ -2395,6 +2405,11 @@ class Parser : public CodeCompletionHandler {
>/// rather than a less-than expression.
>TPResult isTemplateArgumentList(unsigned TokensToSkip);
>
> +  /// Determine whether an '(' after an 'explicit' keyword is part of a
> C++20
> +  /// 'explicit(bool)' declaration, in earlier language modes where that
> is an
> +  /// extension.
> +  TPResult isExplicitBool();
> +
>/// Determine whether an identifier has been tentatively declared as a
>/// non-type. Such tentative declarations should not be found to name a
> type
>/// during a tentative parse, but also should not be annotated as a
> non-type.
>
> diff  --git a/clang/lib/Parse/ParseDecl.cpp b/clang/lib/Parse/ParseDecl.cpp
> index 69a3ed9cbad7..d8c5a0ab02d3 100644
> --- a/clang/lib/Parse/ParseDecl.cpp
> +++ b/clang/lib/Parse/ParseDecl.cpp
> @@ -3617,7 +3617,11 @@ void Parser::ParseDeclarationSpecifiers(DeclSpec
> ,
>ConsumedEnd = ExplicitLoc;
>ConsumeToken(); // kw_explicit
>if (Tok.is(tok::l_paren)) {
> -if (getLangOpts().CPlusPlus2a) {
> +if (getLangOpts().CPlusPlus2a || isExplicitBool() ==
> TPResult::True) {
> +  Diag(Tok.getLocation(), getLangOpts().CPlusPlus2a
> +  ?
> diag::warn_cxx17_compat_explicit_bool
> +  : diag::ext_explicit_bool);
> +
>  

[clang] 45d7080 - PR42694 Support explicit(bool) in older language modes as an extension.

2020-01-15 Thread Richard Smith via cfe-commits

Author: Richard Smith
Date: 2020-01-15T18:38:23-08:00
New Revision: 45d70806f4386adfb62b0d75949a8aad58e0576f

URL: 
https://github.com/llvm/llvm-project/commit/45d70806f4386adfb62b0d75949a8aad58e0576f
DIFF: 
https://github.com/llvm/llvm-project/commit/45d70806f4386adfb62b0d75949a8aad58e0576f.diff

LOG: PR42694 Support explicit(bool) in older language modes as an extension.

This needs somewhat careful disambiguation, as C++2a explicit(bool) is a
breaking change. We only enable it in cases where the source construct
could not possibly be anything else.

Added: 


Modified: 
clang/include/clang/Basic/DiagnosticParseKinds.td
clang/include/clang/Parse/Parser.h
clang/lib/Parse/ParseDecl.cpp
clang/lib/Parse/ParseTentative.cpp
clang/lib/Parse/Parser.cpp
clang/test/SemaCXX/cxx2a-explicit-bool.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticParseKinds.td 
b/clang/include/clang/Basic/DiagnosticParseKinds.td
index cc6a74ac3e6d..41f788e7d9bd 100644
--- a/clang/include/clang/Basic/DiagnosticParseKinds.td
+++ b/clang/include/clang/Basic/DiagnosticParseKinds.td
@@ -33,10 +33,6 @@ def err_asm_goto_cannot_have_output : Error<
 
 let CategoryName = "Parse Issue" in {
 
-def warn_cxx2a_compat_explicit_bool : Warning<
-  "this expression will be parsed as explicit(bool) in C++2a">,
-  InGroup, DefaultIgnore;
-
 def ext_empty_translation_unit : Extension<
   "ISO C requires a translation unit to contain at least one declaration">,
   InGroup>;
@@ -684,6 +680,15 @@ def err_ms_property_expected_comma_or_rparen : Error<
 def err_ms_property_initializer : Error<
   "property declaration cannot have an in-class initializer">;
 
+def warn_cxx2a_compat_explicit_bool : Warning<
+  "this expression will be parsed as explicit(bool) in C++2a">,
+  InGroup, DefaultIgnore;
+def warn_cxx17_compat_explicit_bool : Warning<
+  "explicit(bool) is incompatible with C++ standards before C++2a">,
+  InGroup, DefaultIgnore;
+def ext_explicit_bool : ExtWarn<"explicit(bool) is a C++2a extension">,
+  InGroup;
+
 /// C++ Templates
 def err_expected_template : Error<"expected template">;
 def err_unknown_template_name : Error<

diff  --git a/clang/include/clang/Parse/Parser.h 
b/clang/include/clang/Parse/Parser.h
index e320c9647818..b7bed4713992 100644
--- a/clang/include/clang/Parse/Parser.h
+++ b/clang/include/clang/Parse/Parser.h
@@ -806,6 +806,16 @@ class Parser : public CodeCompletionHandler {
  bool IsNewScope);
   bool TryAnnotateCXXScopeToken(bool EnteringContext = false);
 
+  bool MightBeCXXScopeToken() {
+return Tok.is(tok::identifier) || Tok.is(tok::coloncolon) ||
+   (Tok.is(tok::annot_template_id) &&
+NextToken().is(tok::coloncolon)) ||
+   Tok.is(tok::kw_decltype) || Tok.is(tok::kw___super);
+  }
+  bool TryAnnotateOptionalCXXScopeToken(bool EnteringContext = false) {
+return MightBeCXXScopeToken() && TryAnnotateCXXScopeToken(EnteringContext);
+  }
+
 private:
   enum AnnotatedNameKind {
 /// Annotation has failed and emitted an error.
@@ -2395,6 +2405,11 @@ class Parser : public CodeCompletionHandler {
   /// rather than a less-than expression.
   TPResult isTemplateArgumentList(unsigned TokensToSkip);
 
+  /// Determine whether an '(' after an 'explicit' keyword is part of a C++20
+  /// 'explicit(bool)' declaration, in earlier language modes where that is an
+  /// extension.
+  TPResult isExplicitBool();
+
   /// Determine whether an identifier has been tentatively declared as a
   /// non-type. Such tentative declarations should not be found to name a type
   /// during a tentative parse, but also should not be annotated as a non-type.

diff  --git a/clang/lib/Parse/ParseDecl.cpp b/clang/lib/Parse/ParseDecl.cpp
index 69a3ed9cbad7..d8c5a0ab02d3 100644
--- a/clang/lib/Parse/ParseDecl.cpp
+++ b/clang/lib/Parse/ParseDecl.cpp
@@ -3617,7 +3617,11 @@ void Parser::ParseDeclarationSpecifiers(DeclSpec ,
   ConsumedEnd = ExplicitLoc;
   ConsumeToken(); // kw_explicit
   if (Tok.is(tok::l_paren)) {
-if (getLangOpts().CPlusPlus2a) {
+if (getLangOpts().CPlusPlus2a || isExplicitBool() == TPResult::True) {
+  Diag(Tok.getLocation(), getLangOpts().CPlusPlus2a
+  ? diag::warn_cxx17_compat_explicit_bool
+  : diag::ext_explicit_bool);
+
   ExprResult ExplicitExpr(static_cast(nullptr));
   BalancedDelimiterTracker Tracker(*this, tok::l_paren);
   Tracker.consumeOpen();
@@ -3630,8 +3634,9 @@ void Parser::ParseDeclarationSpecifiers(DeclSpec ,
 Actions.ActOnExplicitBoolSpecifier(ExplicitExpr.get());
   } else
 Tracker.skipToEnd();
-} else
+} else {
   Diag(Tok.getLocation(), diag::warn_cxx2a_compat_explicit_bool);
+}
   }
   

[PATCH] D52193: RFC: [clang] Multithreaded compilation support -- NOT FOR SUBMIT

2020-01-15 Thread Steven Noonan via Phabricator via cfe-commits
tycho added a comment.

I did some local work to make this build and pass almost all tests on Linux as 
well, not to make use of the multi-process features but just to avoid having a 
separate "for Windows only" branch, and to ensure tests pass across platforms. 
Unfortunately my change is not at all acceptable for inclusion because it's 
extremely Linux-specific, and Unix/Program.inc very explicitly says "only use 
generic UNIX code here". I use `pidfd`s and a `timerfd` combined with 
`epoll_wait` to implement `sys::WaitMany`. It works well, but I'd be concerned 
about how to implement this as smoothly for any other *nix platform. 
pidfd/timerfd/epoll made it downright easy, but I started off trying to look at 
options that would work more universally on e.g. Linux *and* the BSDs, but I 
couldn't find anything that wouldn't require building a Rube-Goldberg machine 
juggling timers, alarms, signals, etc, etc.

One thing I noticed in this was one test in particular: `Clang :: 
Driver/cl-fallback.c`. It seems to expose a small design oversight. Since we 
don't ever use `Command::Execute` or the overrides for it, we don't ever fall 
back to the other command in `FallbackCommand::Execute`.

Another thing I see as a big problem for this patch is the change in return 
value for `sys::ExecuteAndWait`. I think the rationale of using `bool` would be 
a good one in a new project: separating execution failure from child process 
runtime failure makes sense. But changing it now does cause problems if you 
merge patches that expect the old return values, and the build silently 
continues (i.e. `if (llvm::sys::ExecuteAndWait(...))` is a common construct). I 
noticed this in particular when I rebased on top of the LLVM master branch, as 
there were several new `sys::ExecuteAndWait` callers (e.g. 
`llvm/tools/llvm-reduce`). The difference in return type would probably be less 
dramatic if it didn't invert the logic (i.e. previously 0 == success, but now 
`true` means success and `0 != true`, so the whole `if(ExecuteAndWait` thing 
breaks terribly). It'd actually be better if the function was renamed or took a 
different set of arguments, just to cause the build to explicitly break so the 
callers could be addressed.

Anyway, I'd love to see this patch or a successor to it move forward, as we'd 
like to start building things with LLVM on *all* platforms where I work, and 
this would greatly help with the issues for the Visual Studio users (which are 
the majority of the prospective users at my office).


Repository:
  rC Clang

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

https://reviews.llvm.org/D52193



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


[PATCH] D72675: Fix -ffast-math/-ffp-contract interaction

2020-01-15 Thread Michael Berg via Phabricator via cfe-commits
mcberg2017 added a comment.

We crossed that bridge internally at Apple a while ago, meaning I have some 
code debt for cleaning up open source for fma formation that uses contract and 
reassoc differently than we do today, both together and separately, case by 
case.


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

https://reviews.llvm.org/D72675



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


[PATCH] D72675: Fix -ffast-math/-ffp-contract interaction

2020-01-15 Thread Warren Ristow via Phabricator via cfe-commits
wristow marked an inline comment as done.
wristow added inline comments.



Comment at: llvm/test/CodeGen/PowerPC/fmf-propagation.ll:201-203
 ; fma(X, 7.0, X * 42.0) --> X * 49.0
-; This is the minimum FMF needed for this transform - the FMA allows 
reassociation.
+; This is the minimum FMF needed for this transform - the 'contract' allows 
the needed reassociation.
+

spatel wrote:
> I was ok with the reasoning up to here, but this example lost me.
> Why does 'contract' alone allow splitting an fma?
> Is 'contract' relevant on anything besides fadd (with an fmul operand)?
I have to admit I'm handwaving here.  I don't really understand why 'contract' 
alone allows this simpliciation:
`fma(X, 7.0, X * 42.0) --> X * 49.0`

to happen.  But either that's correct, or it's a separate bug (and I waved my 
hands about explaining more detail).

The short story is that even without my proposed change, having //only// 
'contract' on the FMA intrinsic results in this being simplified to `X * 49` 
(and also having //only// 'reassoc' did).  The original comment:

`; This is the minimum FMF needed for this transform - the FMA allows 
reassociation.`

is incomplete/misleading.  A more complete comment (relevant before my change) 
would have been:

`; This is the minimum FMF needed for this transform - either 'reassoc' or 
'contract' applied to the FMA intrinsic allows reassociation.`

And with my change, the result is that 'reassoc' is no longer relevant.  But 
since I don't really understand why it should be simplified with only 
`contract`, I should put a TODO comment in.  That is, to me it seems like both 
'contract' //and// 'reassoc' should be needed for this simplification to happen 
(whereas previously it worked with //either// of them individually).  So maybe 
change this comment to:

; This is the minimum FMF needed for this transform - applying 'contract' 
to the FMA intrinsic allows reassociation.
; TODO: It seems 'contract' and 'reassoc' combined should be needed for 
this transform.  Why does it work with only 'contract'?


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

https://reviews.llvm.org/D72675



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


[PATCH] D69868: Allow "callbr" to return non-void values

2020-01-15 Thread Bill Wendling via Phabricator via cfe-commits
void marked an inline comment as done.
void added inline comments.



Comment at: llvm/lib/CodeGen/MachineVerifier.cpp:701
+  } else if (MBB->succ_size() == LandingPadSuccs.size() ||
+ MBB->succ_size() == IndirectPadSuccs.size()) {
 // It's possible that the block legitimately ends with a noreturn

void wrote:
> jyknight wrote:
> > void wrote:
> > > jyknight wrote:
> > > > This isn't correct.
> > > > 
> > > > This line here, is looking at a block which doesn't end in a jump to a 
> > > > successor. So, it's trying to verify that the successor list makes 
> > > > sense in that context.
> > > > 
> > > > The unstated assumption in the code is that the only successors will be 
> > > > landing pads. Instead of actually checking each one, instead it just 
> > > > checks that the count is the number of landing pads, with the 
> > > > assumption that all the successors should be landing pads, and that all 
> > > > the landing pads should be successors.
> > > > 
> > > > The next clause is then checking for the case where there's a 
> > > > fallthrough to the next block. In that case, the successors should've 
> > > > been all the landing pads, and the single fallthrough block.
> > > > 
> > > > Adding similar code to check for the number of callbr targets doesn't 
> > > > really make sense. It's certainly not the case that all callbr targets 
> > > > are targets of all 
> > > > callbr instructions. And even if it was, this still wouldn't be 
> > > > counting things correctly.
> > > > 
> > > > 
> > > > However -- I think i'd expect analyzeBranch to error out (returning 
> > > > true) when confronted by a callbr instruction, because it cannot 
> > > > actually tell what's going on there. If that were the case, nothing in 
> > > > this block should even be invoked. But I guess that's probably not 
> > > > happening, due to the terminator being followed by non-terminators.
> > > > 
> > > > That seems likely to be a problem that needs to be fixed. (And if that 
> > > > is fixed, I think the changes here aren't needed anymore)
> > > > 
> > > > 
> > > Your comment is very confusing. Could you please give an example of where 
> > > this fails?
> > Sorry about that, I should've delimited the parts of that message better...
> > Basically:
> > - Paragraphs 2-4 are describing why the code before this patch appears to 
> > be correct for landing pad, even though it's taking some shortcuts and 
> > making some non-obvious assumptions.
> > - Paragraph 5 ("Adding similar code"...) is why it's not correct for callbr.
> > - Paragraph 6-7 are how I'd suggest to resolve it.
> > 
> > 
> > I believe the code as of your patch will fail validation if you have a 
> > callbr instruction which has a normal-successor block which is an indirect 
> > target of a *different* callbr in the function.
> > 
> > I believe it'll also fail if you have any landing-pad successors, since 
> > those aren't being added to the count of expected successors, but rather 
> > checked separately.
> > 
> > But more seriously than these potential verifier failures, I expect that 
> > analyzeBranch returning wrong answers (in that it may report that a block 
> > unconditionally-jumps to a successor, while it really has both a callbr and 
> > jump, separated by the non-terminator copies) will cause miscompilation. 
> > I'm not sure exactly how that will exhibit, but I'm pretty sure it's not 
> > going to be good.
> > 
> > And, if analyzeBranch properly said "no idea" when confronted by callbr 
> > control flow, then this code in the verifier wouldn't be reached.
> I didn't need a delineation of the parts of the comment. I needed a clearer 
> description of what your concern is, and to give an example of code that 
> fails here.
> 
> This bit of code is simply saying that if the block containing the 
> `INLINEASM_BR` doesn't end with a `BR` instruction, then the number of its 
> successors should be equal to the number of indirect successors. This is 
> correct, as it's not valid to have a duplicate label used in a `callbr` 
> instruction:
> 
> ```
> $ llc -o /dev/null x.ll
> Duplicate callbr destination!
>   %3 = callbr i32 asm sideeffect "testl $0, $0; testl $1, $1; jne ${2:l}", 
> "={si},r,X,0,~{dirflag},~{fpsr},~{flags}"(i32 %2, i8* blockaddress(@test1, 
> %asm.fallthrough), i32 %1) #2
>   to label %asm.fallthrough [label %asm.fallthrough], !srcloc !6
> ./bin/llc: x.ll: error: input module is broken!
> ```
> 
> A `callbr` with a normal successor block that is the indirect target of a 
> different `callbr` isn't really relevant here, unless I'm misunderstanding 
> what `analyzeBranch` returns. There would be two situations:
> 
> 1. The MBB ends in a fallthrough, which is the case I mentioned above, or
> 
> 2. The MBB ends in a `BR` instruction, in which case it won't be in this 
> block of code, but the block below.
> 
> If `analyzeBranch` is not taking into account potential `COPY` instructions 
> 

[PATCH] D71491: [ubsan] Check implicit casts in ObjC for-in statements

2020-01-15 Thread Vedant Kumar via Phabricator via cfe-commits
vsk added inline comments.



Comment at: compiler-rt/lib/ubsan/ubsan_value.cpp:29
+const char *__ubsan::getObjCClassName(ValueHandle Pointer) {
+#if defined(__APPLE__)
+  // We need to query the ObjC runtime for some information, but do not want

delcypher wrote:
> vsk wrote:
> > delcypher wrote:
> > > vsk wrote:
> > > > delcypher wrote:
> > > > > The compiler-rt codebase tends to use `SANITIZER_MAC` macro (defined 
> > > > > to be 1 if Apple otherwise it's 0) rather than `__APPLE__`.
> > > > I see. That seems problematic, as it makes it tricky to add 
> > > > macOS-specific (or iOS-specific) functionality down the road. I don't 
> > > > think SANITIZER_MAC should be defined unless TARGET_OS_MACOS is true.
> > > Sorry I should clarify. `SANITIZER_MAC` is poorly named but it is defined 
> > > to be `1` for Apple platforms and `0`. I'm just pointing out the 
> > > convention that exists today. You're absolutely right that we might want 
> > > to do different things for different Apple platforms but I don't think we 
> > > want to start doing a mass re-name until arm64e and arm64_32 support are 
> > > completed landed in llvm's master.
> > I think 'SANITIZER_MAC' is confusing, and my preference would be to not use 
> > it. `__APPLE__` seems clearer to me, and (IIUC) the plan is to replace 
> > usage of 'SANITIZER_MAC' with it down the line anyway?
> There aren't any plans to do it right now but cleaning this up seems like a 
> reasonable thing to do. If you take a look at 
> `compiler-rt/lib/sanitizer_common/sanitizer_platform.h` you'll see that we 
> actually have `SANITIZER_` for the other platforms that seems to be 
> set as you'd expect. It's just `SANITIZER_MAC` that's badly named.
> 
> I've filed a radar for this issue (rdar://problem/58124919). So if you prefer 
> to use `__APPLE__` could you leave a comment with something like
> 
> ```
> // TODO(dliew): Don't use unclear `SANITIZER_MAC` here. Instead wait for its 
> replacement rdar://problem/58124919.
> ```
> 
> Note the `TODO():` style is enforced by the sanitizer specific linter 
> so you have to put a name there.
Thanks, done!


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

https://reviews.llvm.org/D71491



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


[PATCH] D71491: [ubsan] Check implicit casts in ObjC for-in statements

2020-01-15 Thread Vedant Kumar via Phabricator via cfe-commits
vsk updated this revision to Diff 238393.
vsk marked an inline comment as done.

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

https://reviews.llvm.org/D71491

Files:
  clang/docs/UndefinedBehaviorSanitizer.rst
  clang/include/clang/Basic/Sanitizers.def
  clang/lib/CodeGen/CGObjC.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/Driver/SanitizerArgs.cpp
  clang/lib/Driver/ToolChains/Darwin.cpp
  clang/test/CodeGenObjC/for-in.m
  compiler-rt/lib/ubsan/ubsan_checks.inc
  compiler-rt/lib/ubsan/ubsan_handlers.cpp
  compiler-rt/lib/ubsan/ubsan_handlers.h
  compiler-rt/lib/ubsan/ubsan_value.cpp
  compiler-rt/lib/ubsan/ubsan_value.h
  compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp
  compiler-rt/test/ubsan/TestCases/Misc/objc-cast.m

Index: compiler-rt/test/ubsan/TestCases/Misc/objc-cast.m
===
--- /dev/null
+++ compiler-rt/test/ubsan/TestCases/Misc/objc-cast.m
@@ -0,0 +1,22 @@
+// REQUIRES: darwin
+//
+// RUN: %clang -framework Foundation -fsanitize=objc-cast %s -O1 -o %t
+// RUN: %run %t 2>&1 | FileCheck %s
+//
+// RUN: %clang -framework Foundation -fsanitize=objc-cast -fno-sanitize-recover=objc-cast %s -O1 -o %t.trap
+// RUN: not %run %t.trap 2>&1 | FileCheck %s
+
+#include 
+
+int main() {
+  NSArray *array = [NSArray arrayWithObjects: @1, @2, @3, (void *)0];
+  // CHECK: objc-cast.m:[[@LINE+1]]:{{.*}}: runtime error: invalid ObjC cast, object is a '__NSCFNumber', but expected a 'NSString'
+  for (NSString *str in array) {
+NSLog(@"%@", str);
+  }
+
+  // The diagnostic should only be printed once.
+  // CHECK-NOT: runtime error
+
+  return 0;
+}
Index: compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp
===
--- compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp
+++ compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp
@@ -109,6 +109,7 @@
 HANDLER(float_cast_overflow, "float-cast-overflow")
 HANDLER(load_invalid_value, "load-invalid-value")
 HANDLER(invalid_builtin, "invalid-builtin")
+HANDLER(invalid_objc_cast, "invalid-objc-cast")
 HANDLER(function_type_mismatch, "function-type-mismatch")
 HANDLER(implicit_conversion, "implicit-conversion")
 HANDLER(nonnull_arg, "nonnull-arg")
Index: compiler-rt/lib/ubsan/ubsan_value.h
===
--- compiler-rt/lib/ubsan/ubsan_value.h
+++ compiler-rt/lib/ubsan/ubsan_value.h
@@ -135,6 +135,9 @@
 /// \brief An opaque handle to a value.
 typedef uptr ValueHandle;
 
+/// Returns the class name of the given ObjC object, or null if the name
+/// cannot be found.
+const char *getObjCClassName(ValueHandle Pointer);
 
 /// \brief Representation of an operand value provided by the instrumented code.
 ///
Index: compiler-rt/lib/ubsan/ubsan_value.cpp
===
--- compiler-rt/lib/ubsan/ubsan_value.cpp
+++ compiler-rt/lib/ubsan/ubsan_value.cpp
@@ -16,9 +16,57 @@
 #include "ubsan_value.h"
 #include "sanitizer_common/sanitizer_common.h"
 #include "sanitizer_common/sanitizer_libc.h"
+#include "sanitizer_common/sanitizer_mutex.h"
+
+// TODO(dliew): Prefer '__APPLE__' here over 'SANITIZER_MAC', as the latter is
+// unclear. rdar://58124919 tracks using a more obviously portable guard.
+#if defined(__APPLE__)
+#include 
+#endif
 
 using namespace __ubsan;
 
+typedef const char *(*ObjCGetClassNameTy)(void *);
+
+const char *__ubsan::getObjCClassName(ValueHandle Pointer) {
+#if defined(__APPLE__)
+  // We need to query the ObjC runtime for some information, but do not want
+  // to introduce a static dependency from the ubsan runtime onto ObjC. Try to
+  // grab a handle to the ObjC runtime used by the process.
+  static bool AttemptedDlopen = false;
+  static void *ObjCHandle = nullptr;
+  static void *ObjCObjectGetClassName = nullptr;
+
+  // Prevent threads from racing to dlopen().
+  static __sanitizer::StaticSpinMutex Lock;
+  {
+__sanitizer::SpinMutexLock Guard();
+
+if (!AttemptedDlopen) {
+  ObjCHandle = dlopen(
+  "/usr/lib/libobjc.A.dylib",
+  RTLD_LAZY // Only bind symbols when used.
+  | RTLD_LOCAL  // Only make symbols available via the handle.
+  | RTLD_NOLOAD // Do not load the dylib, just grab a handle if the
+// image is already loaded.
+  | RTLD_FIRST  // Only search the image pointed-to by the handle.
+  );
+  AttemptedDlopen = true;
+  if (!ObjCHandle)
+return nullptr;
+  ObjCObjectGetClassName = dlsym(ObjCHandle, "object_getClassName");
+}
+  }
+
+  if (!ObjCObjectGetClassName)
+return nullptr;
+
+  return ObjCGetClassNameTy(ObjCObjectGetClassName)((void *)Pointer);
+#else
+  return nullptr;
+#endif
+}
+
 SIntMax Value::getSIntValue() const {
   CHECK(getType().isSignedIntegerTy());
   if (isInlineInt()) {
Index: compiler-rt/lib/ubsan/ubsan_handlers.h

Re: [clang] e8f198d - Fix pack deduction to only deduce the arity of packs that are actually

2020-01-15 Thread Richard Smith via cfe-commits
Hi Hans,

Please consider this bugfix for the Clang 10 release branch.

On Wed, 15 Jan 2020 at 16:21, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
> Author: Richard Smith
> Date: 2020-01-15T16:21:08-08:00
> New Revision: e8f198dd9e9dabed8d50276465906e7c8827cada
>
> URL:
> https://github.com/llvm/llvm-project/commit/e8f198dd9e9dabed8d50276465906e7c8827cada
> DIFF:
> https://github.com/llvm/llvm-project/commit/e8f198dd9e9dabed8d50276465906e7c8827cada.diff
>
> LOG: Fix pack deduction to only deduce the arity of packs that are actually
> expanded by the deduced pack.
>
> We recently started also deducing the arity of separately-expanded packs
> that are merely mentioned within the pack in question, which is
> incorrect.
>
> Added:
>
>
> Modified:
> clang/lib/Sema/SemaTemplateDeduction.cpp
> clang/test/SemaTemplate/deduction.cpp
>
> Removed:
>
>
>
>
> 
> diff  --git a/clang/lib/Sema/SemaTemplateDeduction.cpp
> b/clang/lib/Sema/SemaTemplateDeduction.cpp
> index 1b9f1b2144d1..048a50a741e4 100644
> --- a/clang/lib/Sema/SemaTemplateDeduction.cpp
> +++ b/clang/lib/Sema/SemaTemplateDeduction.cpp
> @@ -724,38 +724,48 @@ class PackDeductionScope {
>  // Compute the set of template parameter indices that correspond to
>  // parameter packs expanded by the pack expansion.
>  llvm::SmallBitVector SawIndices(TemplateParams->size());
> +llvm::SmallVector ExtraDeductions;
>
>  auto AddPack = [&](unsigned Index) {
>if (SawIndices[Index])
>  return;
>SawIndices[Index] = true;
>addPack(Index);
> +
> +  // Deducing a parameter pack that is a pack expansion also
> constrains the
> +  // packs appearing in that parameter to have the same deduced
> arity. Also,
> +  // in C++17 onwards, deducing a non-type template parameter deduces
> its
> +  // type, so we need to collect the pending deduced values for those
> packs.
> +  if (auto *NTTP = dyn_cast(
> +  TemplateParams->getParam(Index))) {
> +if (auto *Expansion =
> dyn_cast(NTTP->getType()))
> +  ExtraDeductions.push_back(Expansion->getPattern());
> +  }
> +  // FIXME: Also collect the unexpanded packs in any type and template
> +  // parameter packs that are pack expansions.
>  };
>
> -// First look for unexpanded packs in the pattern.
> -SmallVector Unexpanded;
> -S.collectUnexpandedParameterPacks(Pattern, Unexpanded);
> -for (unsigned I = 0, N = Unexpanded.size(); I != N; ++I) {
> -  unsigned Depth, Index;
> -  std::tie(Depth, Index) = getDepthAndIndex(Unexpanded[I]);
> -  if (Depth == Info.getDeducedDepth())
> -AddPack(Index);
> -}
> +auto Collect = [&](TemplateArgument Pattern) {
> +  SmallVector Unexpanded;
> +  S.collectUnexpandedParameterPacks(Pattern, Unexpanded);
> +  for (unsigned I = 0, N = Unexpanded.size(); I != N; ++I) {
> +unsigned Depth, Index;
> +std::tie(Depth, Index) = getDepthAndIndex(Unexpanded[I]);
> +if (Depth == Info.getDeducedDepth())
> +  AddPack(Index);
> +  }
> +};
> +
> +// Look for unexpanded packs in the pattern.
> +Collect(Pattern);
>  assert(!Packs.empty() && "Pack expansion without unexpanded packs?");
>
>  unsigned NumNamedPacks = Packs.size();
>
> -// We can also have deduced template parameters that do not actually
> -// appear in the pattern, but can be deduced by it (the type of a
> non-type
> -// template parameter pack, in particular). These won't have
> prevented us
> -// from partially expanding the pack.
> -llvm::SmallBitVector Used(TemplateParams->size());
> -MarkUsedTemplateParameters(S.Context, Pattern, /*OnlyDeduced*/true,
> -   Info.getDeducedDepth(), Used);
> -for (int Index = Used.find_first(); Index != -1;
> - Index = Used.find_next(Index))
> -  if (TemplateParams->getParam(Index)->isParameterPack())
> -AddPack(Index);
> +// Also look for unexpanded packs that are indirectly deduced by
> deducing
> +// the sizes of the packs in this pattern.
> +while (!ExtraDeductions.empty())
> +  Collect(ExtraDeductions.pop_back_val());
>
>  return NumNamedPacks;
>}
>
> diff  --git a/clang/test/SemaTemplate/deduction.cpp
> b/clang/test/SemaTemplate/deduction.cpp
> index 1f1c30a8b4ab..7268912dd6c5 100644
> --- a/clang/test/SemaTemplate/deduction.cpp
> +++ b/clang/test/SemaTemplate/deduction.cpp
> @@ -546,3 +546,21 @@ namespace designators {
>
>static_assert(f({.a = 1, .b = 2}) == 3, ""); // expected-error {{no
> matching function}}
>  }
> +
> +namespace nested_packs {
> +  template void f(T (*...f)(U...)); //
> expected-note {{deduced packs of
> diff erent lengths for parameter 'U' (<> vs. )}}
> +  void g() { f(g); f(g, g); f(g, g, g); }
> +  void h(int) { f(h); f(h, h); f(h, h, h); }
> +  void i() { f(g, 

[clang] e8f198d - Fix pack deduction to only deduce the arity of packs that are actually

2020-01-15 Thread Richard Smith via cfe-commits

Author: Richard Smith
Date: 2020-01-15T16:21:08-08:00
New Revision: e8f198dd9e9dabed8d50276465906e7c8827cada

URL: 
https://github.com/llvm/llvm-project/commit/e8f198dd9e9dabed8d50276465906e7c8827cada
DIFF: 
https://github.com/llvm/llvm-project/commit/e8f198dd9e9dabed8d50276465906e7c8827cada.diff

LOG: Fix pack deduction to only deduce the arity of packs that are actually
expanded by the deduced pack.

We recently started also deducing the arity of separately-expanded packs
that are merely mentioned within the pack in question, which is
incorrect.

Added: 


Modified: 
clang/lib/Sema/SemaTemplateDeduction.cpp
clang/test/SemaTemplate/deduction.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaTemplateDeduction.cpp 
b/clang/lib/Sema/SemaTemplateDeduction.cpp
index 1b9f1b2144d1..048a50a741e4 100644
--- a/clang/lib/Sema/SemaTemplateDeduction.cpp
+++ b/clang/lib/Sema/SemaTemplateDeduction.cpp
@@ -724,38 +724,48 @@ class PackDeductionScope {
 // Compute the set of template parameter indices that correspond to
 // parameter packs expanded by the pack expansion.
 llvm::SmallBitVector SawIndices(TemplateParams->size());
+llvm::SmallVector ExtraDeductions;
 
 auto AddPack = [&](unsigned Index) {
   if (SawIndices[Index])
 return;
   SawIndices[Index] = true;
   addPack(Index);
+
+  // Deducing a parameter pack that is a pack expansion also constrains the
+  // packs appearing in that parameter to have the same deduced arity. 
Also,
+  // in C++17 onwards, deducing a non-type template parameter deduces its
+  // type, so we need to collect the pending deduced values for those 
packs.
+  if (auto *NTTP = dyn_cast(
+  TemplateParams->getParam(Index))) {
+if (auto *Expansion = dyn_cast(NTTP->getType()))
+  ExtraDeductions.push_back(Expansion->getPattern());
+  }
+  // FIXME: Also collect the unexpanded packs in any type and template
+  // parameter packs that are pack expansions.
 };
 
-// First look for unexpanded packs in the pattern.
-SmallVector Unexpanded;
-S.collectUnexpandedParameterPacks(Pattern, Unexpanded);
-for (unsigned I = 0, N = Unexpanded.size(); I != N; ++I) {
-  unsigned Depth, Index;
-  std::tie(Depth, Index) = getDepthAndIndex(Unexpanded[I]);
-  if (Depth == Info.getDeducedDepth())
-AddPack(Index);
-}
+auto Collect = [&](TemplateArgument Pattern) {
+  SmallVector Unexpanded;
+  S.collectUnexpandedParameterPacks(Pattern, Unexpanded);
+  for (unsigned I = 0, N = Unexpanded.size(); I != N; ++I) {
+unsigned Depth, Index;
+std::tie(Depth, Index) = getDepthAndIndex(Unexpanded[I]);
+if (Depth == Info.getDeducedDepth())
+  AddPack(Index);
+  }
+};
+
+// Look for unexpanded packs in the pattern.
+Collect(Pattern);
 assert(!Packs.empty() && "Pack expansion without unexpanded packs?");
 
 unsigned NumNamedPacks = Packs.size();
 
-// We can also have deduced template parameters that do not actually
-// appear in the pattern, but can be deduced by it (the type of a non-type
-// template parameter pack, in particular). These won't have prevented us
-// from partially expanding the pack.
-llvm::SmallBitVector Used(TemplateParams->size());
-MarkUsedTemplateParameters(S.Context, Pattern, /*OnlyDeduced*/true,
-   Info.getDeducedDepth(), Used);
-for (int Index = Used.find_first(); Index != -1;
- Index = Used.find_next(Index))
-  if (TemplateParams->getParam(Index)->isParameterPack())
-AddPack(Index);
+// Also look for unexpanded packs that are indirectly deduced by deducing
+// the sizes of the packs in this pattern.
+while (!ExtraDeductions.empty())
+  Collect(ExtraDeductions.pop_back_val());
 
 return NumNamedPacks;
   }

diff  --git a/clang/test/SemaTemplate/deduction.cpp 
b/clang/test/SemaTemplate/deduction.cpp
index 1f1c30a8b4ab..7268912dd6c5 100644
--- a/clang/test/SemaTemplate/deduction.cpp
+++ b/clang/test/SemaTemplate/deduction.cpp
@@ -546,3 +546,21 @@ namespace designators {
 
   static_assert(f({.a = 1, .b = 2}) == 3, ""); // expected-error {{no matching 
function}}
 }
+
+namespace nested_packs {
+  template void f(T (*...f)(U...)); // 
expected-note {{deduced packs of 
diff erent lengths for parameter 'U' (<> vs. )}}
+  void g() { f(g); f(g, g); f(g, g, g); }
+  void h(int) { f(h); f(h, h); f(h, h, h); }
+  void i() { f(g, h); } // expected-error {{no matching function}}
+
+#if __cplusplus >= 201703L
+  template struct Q {};
+  template void q(Q, Q); // #q
+  void qt(Q<> q0, Q<1, 2> qii, Q<1, 2, 3> qiii) {
+q(q0, q0);
+q(qii, qii);
+q(qii, qiii); // expected-error {{no match}} expected-note@#q {{deduced 
packs of 
diff erent lengths for parameter 'T' ( vs. )}}
+q(q0, qiii); // 

[PATCH] D44352: [Concepts] Type Constraints

2020-01-15 Thread Yuanfang Chen via Phabricator via cfe-commits
ychen added a comment.

I saw a null pointer dereference for the `p3-2a.cpp` file added here. It is not 
always reproducible for me, I was able to reproduce it once offline. Any idea?

Crash stack is here:
https://results.llvm-merge-guard.org/amd64_debian_testing_clang8-1220/console-log.txt

From D67847 , you could see that the first 
time merge bot is ran,  `p3-2a.cpp` failed. The second time, without me doing 
anything except updating some unrelated tests,  `p3-2a.cpp` passes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D44352



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


[PATCH] D72380: [DataFlow] Factor two worklist implementations out

2020-01-15 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun added a comment.

Here is an example:

  void f() {
int i;
while (i < 42 && i) {
  if (i)

}
  }

This takes 17 visits before, 16 after.


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

https://reviews.llvm.org/D72380



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


Re: [clang] 23058f9 - [OPENMP]Do not use RTTI by default for NVPTX devices.

2020-01-15 Thread Artem Belevich via cfe-commits
On Wed, Jan 15, 2020 at 3:09 PM Alexey Bataev  wrote:

> And I disabled it only for device side, which is NVPTX, no? Can host side
> target class report that the target is NVPTX? If you look at the patch, it
> disable RTTI only if current triple is NVPTX. Can it be true for the host?
>
You are correct that the NVPTX as the triple is never used for the host
compilation.

However, I'm talking about host-side *code* as seen by compiler during
device-side *compilation*. Keep in mind that both host and device
compilations always see both sides of the source code. The host code seen
by the compiler during device-side compilation should be allowed to use
host features that are not available on GPU.

When you RTTI got disabled for NVPTX, it affected *all* code seen by the
compiler. When GPU-side compiler that targets NVPTX with RTTI disabled gets
to parse the host function hf() (https://godbolt.org/z/Gzsrof) it sees
typeid() and complains that RTTI is disabled, even though it will never
produce any code for hf(). It should've allowed RTTI use in the host-only
code.

--Artem





> -
> Best regards,
> Alexey Bataev
>
> 15.01.2020 1:06 PM, Artem Belevich пишет:
>
>
>
> On Wed, Jan 15, 2020 at 2:52 PM Alexey Bataev 
> wrote:
>
>> 1. The problem is that it does not produce errors,
>>
> ATM, it does produce errors when it's disabled.
>
>> it leads to the emission of some declaration that cannot be resolved by
>> the linker. This what I was trying to avoid.
>>
> I'm OK with disabling it on device, but it should be done in a way to keep
> RTTI in the host code working.
>
> E.g. this code should compile: https://godbolt.org/z/Gzsrof
> It still has your original change, so clang compilation fails. It does not
> with NVCC.
>
> 2. Yes, I did not disable it on the host side, just for the device side. I
>> disabled it only for NVPTX target, which is the device.
>>
> It's fine to disable it for code generated for the target. However, the
> front-end needs to be able to deal with the host-side code where it is OK
> to use RTTI.
>
> --Artem
>
>
>
>
>> -
>> Best regards,
>> Alexey Bataev
>>
>> 15.01.2020 12:49 PM, Artem Belevich пишет:
>>
>> Thank you.
>>
>> In general, RTTI should probably be treated similar to how we deal with
>> inline assembly and ignore errors if they are in the code that we're not
>> going to codegen during this side of compilation. E.g. during host-side
>> compilation we don't complain about GPU-side registers in inline assembly
>> that x86 target is not aware of.
>>
>> Disabling RTTI altogether on device side makes it impossible to use in
>> any host-side CUDA because RTTI code will be seen by the device-side
>> compiler, which will promptly fail, which is exactly what happened in this
>> case -- host-side template that relied on RTTI failed during device-side
>> compilation:
>>
>>
>> https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/arena.h#L536
>> google/protobuf/arena.h:536:15: error: use of typeid requires -frtti
>> AllocHook(RTTI_TYPE_ID(T), n);
>> ...
>> 2 errors generated when compiling for sm_60.
>>
>> --Artem
>>
>> On Wed, Jan 15, 2020 at 2:36 PM Alexey Bataev 
>> wrote:
>>
>>> Sure, will revert it ASAP.
>>>
>>> -
>>> Best regards,
>>> Alexey Bataev
>>>
>>> 15.01.2020 12:26 PM, Artem Belevich пишет:
>>>
>>> Alexey,
>>>
>>> This breaks compilation of our cuda code which happens to transitively
>>> include protobuf headers.
>>> Can you, please, revert it for now until we figure out how RTTI should
>>> be handled?
>>>
>>> --Artem
>>>
>>> On Tue, Jan 14, 2020 at 3:15 PM Alexey Bataev via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>

 Author: Alexey Bataev
 Date: 2020-01-14T18:12:06-05:00
 New Revision: 23058f9dd4d7e18239fd63b6da52549514b45fda

 URL:
 https://github.com/llvm/llvm-project/commit/23058f9dd4d7e18239fd63b6da52549514b45fda
 DIFF:
 https://github.com/llvm/llvm-project/commit/23058f9dd4d7e18239fd63b6da52549514b45fda.diff

 LOG: [OPENMP]Do not use RTTI by default for NVPTX devices.

 NVPTX does not support RTTI, so disable it by default.

 Added:
 clang/test/Driver/openmp-offload-gpu.cpp

 Modified:
 clang/lib/Driver/ToolChain.cpp

 Removed:




 
 diff  --git a/clang/lib/Driver/ToolChain.cpp
 b/clang/lib/Driver/ToolChain.cpp
 index cab97b1a601a..3ebbd30195b3 100644
 --- a/clang/lib/Driver/ToolChain.cpp
 +++ b/clang/lib/Driver/ToolChain.cpp
 @@ -68,7 +68,8 @@ static ToolChain::RTTIMode CalculateRTTIMode(const
 ArgList ,
}

// -frtti is default, except for the PS4 CPU.
 -  return (Triple.isPS4CPU()) ? ToolChain::RM_Disabled :
 ToolChain::RM_Enabled;
 +  return (Triple.isPS4CPU() || Triple.isNVPTX()) ?
 ToolChain::RM_Disabled
 +

[clang] 4456076 - Revert "Further implement CWG 2292"

2020-01-15 Thread Amy Huang via cfe-commits

Author: Amy Huang
Date: 2020-01-15T15:46:07-08:00
New Revision: 44560762c62d72a103bdceff49ffa70451efd5f8

URL: 
https://github.com/llvm/llvm-project/commit/44560762c62d72a103bdceff49ffa70451efd5f8
DIFF: 
https://github.com/llvm/llvm-project/commit/44560762c62d72a103bdceff49ffa70451efd5f8.diff

LOG: Revert "Further implement CWG 2292"

This reverts commit ee0f1f1edc3ec0d4e698d50cc3180217448802b7 because it
causes an error on valid code.
See https://reviews.llvm.org/rGee0f1f1edc3ec0d4e698d50cc3180217448802b7.

Added: 


Modified: 
clang/lib/Sema/SemaExprCXX.cpp

Removed: 
clang/test/SemaCXX/pseudo-destructor-name.cpp



diff  --git a/clang/lib/Sema/SemaExprCXX.cpp b/clang/lib/Sema/SemaExprCXX.cpp
index 96e18105df78..a73e6906fceb 100644
--- a/clang/lib/Sema/SemaExprCXX.cpp
+++ b/clang/lib/Sema/SemaExprCXX.cpp
@@ -192,10 +192,8 @@ ParsedType Sema::getDestructorName(SourceLocation TildeLoc,
   AlreadySearched = true;
   LookupCtx = DC;
   isDependent = false;
-} else if (auto *RD = dyn_cast_or_null(DC)) {
-  if ((RD->hasDefinition() && RD->hasSimpleDestructor()) ||
-  !RD->hasDefinition())
-LookAtPrefix = false;
+} else if (DC && isa(DC)) {
+  LookAtPrefix = false;
   LookInScope = true;
 }
 

diff  --git a/clang/test/SemaCXX/pseudo-destructor-name.cpp 
b/clang/test/SemaCXX/pseudo-destructor-name.cpp
deleted file mode 100644
index cc7c22b8dc4d..
--- a/clang/test/SemaCXX/pseudo-destructor-name.cpp
+++ /dev/null
@@ -1,26 +0,0 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -std=c++11 %s
-// expected-no-diagnostics
-
-struct AAA
-{
-struct BBB
-{
-~BBB() {}
-};
-
-typedef BBB BBB_alias;
-};
-
-typedef AAA::BBB BBB_alias2;
-
-int
-main()
-{
-AAA::BBB_alias *ptr1 = new AAA::BBB_alias();
-AAA::BBB_alias *ptr2 = new AAA::BBB_alias();
-
-ptr1->AAA::BBB_alias::~BBB_alias(); // Now OK
-ptr2->AAA::BBB_alias::~BBB();   // OK
-ptr1->~BBB_alias2();// OK
-return 0;
-}



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


[clang] b841b9e - [OPENMP]Use regular processing of vtable used when TU is a prefix.

2020-01-15 Thread Alexey Bataev via cfe-commits

Author: Alexey Bataev
Date: 2020-01-15T18:42:23-05:00
New Revision: b841b9e96e605bed5a1f9b846a07aae88c65ce02

URL: 
https://github.com/llvm/llvm-project/commit/b841b9e96e605bed5a1f9b846a07aae88c65ce02
DIFF: 
https://github.com/llvm/llvm-project/commit/b841b9e96e605bed5a1f9b846a07aae88c65ce02.diff

LOG: [OPENMP]Use regular processing of vtable used when TU is a prefix.

If current kind of the translation unit is TU_Prefix and it is not
complete, cannot decide what to do with virtual members/table at that
time, need to delay it to later stages.

Added: 


Modified: 
clang/lib/Sema/SemaDeclCXX.cpp
clang/test/OpenMP/declare_target_codegen.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaDeclCXX.cpp b/clang/lib/Sema/SemaDeclCXX.cpp
index 9916d3be77e1..d1e720ebcc2a 100644
--- a/clang/lib/Sema/SemaDeclCXX.cpp
+++ b/clang/lib/Sema/SemaDeclCXX.cpp
@@ -16743,7 +16743,7 @@ void Sema::MarkVTableUsed(SourceLocation Loc, 
CXXRecordDecl *Class,
 return;
   // Do not mark as used if compiling for the device outside of the target
   // region.
-  if (LangOpts.OpenMP && LangOpts.OpenMPIsDevice &&
+  if (TUKind != TU_Prefix && LangOpts.OpenMP && LangOpts.OpenMPIsDevice &&
   !isInOpenMPDeclareTargetContext() &&
   !isInOpenMPTargetExecutionDirective()) {
 if (!DefinitionRequired)

diff  --git a/clang/test/OpenMP/declare_target_codegen.cpp 
b/clang/test/OpenMP/declare_target_codegen.cpp
index 165ba097b95e..abe94c98734c 100644
--- a/clang/test/OpenMP/declare_target_codegen.cpp
+++ b/clang/test/OpenMP/declare_target_codegen.cpp
@@ -1,7 +1,7 @@
-// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown 
-fopenmp-targets=powerpc64le-ibm-linux-gnu -emit-llvm-bc %s -o %t-ppc-host.bc
-// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown 
-emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o - 
| FileCheck %s
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown 
-fopenmp-targets=powerpc64le-ibm-linux-gnu -emit-llvm-bc %s -o %t-ppc-host.bc 
-DLOAD
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown 
-emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o - 
-DLOAD | FileCheck %s
 // RUN: %clang_cc1 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown 
-emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc 
-emit-pch -o %t
-// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown 
-emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc 
-include-pch %t -o - | FileCheck %s
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown 
-emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc 
-include-pch %t -o - -DLOAD | FileCheck %s
 
 // RUN: %clang_cc1 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown 
-fopenmp-targets=powerpc64le-ibm-linux-gnu -emit-llvm %s -o - 
-fopenmp-version=50 -DOMP5 | FileCheck %s --check-prefix HOST5
 // RUN: %clang_cc1 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown 
-fopenmp-targets=powerpc64le-ibm-linux-gnu -emit-llvm-bc %s -o %t-ppc-host.bc 
-fopenmp-version=50 -DOMP5
@@ -231,6 +231,16 @@ int main() {
 // CHECK-DAG: define {{.*}}void 
@__omp_offloading_{{.*}}virtual_foo{{.*}}_l[[@LINE-25]]()
 // CHECK-DAG: define {{.*}}void 
@__omp_offloading_{{.*}}emitted{{.*}}_l[[@LINE-11]]()
 
+template 
+struct TTT {
+  virtual void emitted() {
+#pragma omp target
+  {}
+  }
+};
+
+// CHECK-DAG: define {{.*}}void 
@__omp_offloading_{{.*}}emitted{{.*}}_l[[@LINE-5]]()
+
 // CHECK-DAG: declare extern_weak signext i32 @__create()
 
 // CHECK-NOT: define {{.*}}{{baz1|baz4|maini1|Base|virtual_}}
@@ -254,3 +264,12 @@ void device_fun() {}
 #endif // OMP5
 
 #endif // HEADER
+
+#ifdef LOAD
+#pragma omp declare target
+void new_bar1() {
+  TTT *X = new TTT();
+  X->emitted();
+}
+#pragma omp end declare target
+#endif



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


[PATCH] D72380: [DataFlow] Factor two worklist implementations out

2020-01-15 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun added a comment.

In D72380#1823019 , @xazax.hun wrote:

> In D72380#1822927 , @NoQ wrote:
>
> > The change in uninitialized values analysis gives me a bit of anxiety. 
> > Could you explain what exactly has changed that caused the change in the 
> > stats and why you think it doesn't make a difference, maybe give an 
> > example? (an example could be obtained by `creduce`-ing over "the stats 
> > have changed" criterion)
>
>
> We will process it multiple times with the original implementation, we 
> traverse the CFG both using DFS and using reverse post order.


Sorry, I just realized that the original code initially considers all the nodes 
queued. In this case there is no extra pass. But it is still true that the 
original is mostly using DFS while the new one is only using RPO. So it comes 
down to the order we visit the basic blocks. Working on a minimal repro.


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

https://reviews.llvm.org/D72380



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


[PATCH] D72380: [DataFlow] Factor two worklist implementations out

2020-01-15 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun added a comment.

In D72380#1822927 , @NoQ wrote:

> The change in uninitialized values analysis gives me a bit of anxiety. Could 
> you explain what exactly has changed that caused the change in the stats and 
> why you think it doesn't make a difference, maybe give an example? (an 
> example could be obtained by `creduce`-ing over "the stats have changed" 
> criterion)


Yeah, this is the riskiest part, so I do understand the concerns. Basically, 
the former implementation was using `PostOrderCFGView::iterator`s and a stack 
(popping from the back of a smallvector). When the stack was empty, it popped 
the next element from the iterator. Also, the analysis queues the successors of 
a node once it was processed (and the analysis state was changed).
So let's imagine a linear CFG. We will process it multiple times with the 
original implementation, we traverse the CFG both using DFS and using reverse 
post order.

The new implementation is only using a reverse post order (no stack, no DFS), 
and does not have an extra pass over the CFG like the previous one.

Since this is a fixed point iteration and we should stop iterating whenever we 
reached the fixed point. Reaching that with fewer iterations sounds good to me. 
Since we always queue the successors of a changed node I have hard time 
imagining how could we stop prematurely.

I can look into a minimal repro if that helps.


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

https://reviews.llvm.org/D72380



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


[PATCH] D72811: [WIP][OPENMP5.0] allow lvalue for motion clause

2020-01-15 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added inline comments.



Comment at: clang/lib/CodeGen/CGOpenMPRuntime.cpp:7709-7712
 isa(Next->getAssociatedExpression()) ||
 isa(Next->getAssociatedExpression()) ||
-isa(Next->getAssociatedExpression())) &&
+isa(Next->getAssociatedExpression()) ||
+isa(Next->getAssociatedExpression())) &&

This assertion must check that the expression is just an lvalue, no?



Comment at: clang/lib/Sema/SemaOpenMP.cpp:15442-15443
+  CurComponents.emplace_back(CurE, nullptr);
+} else if (auto *CurE = dyn_cast(E)) {
+  E = CurE->getLHS()->IgnoreParenImpCasts();
 } else {

Why just the LHS is analyzed? Also, what about support for other expressions, 
like casting, call, choose etc., which may result in lvalue?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72811



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


[PATCH] D70700: [WebAssembly] Mangle the argc/argv `main` as `__main_argc_argv`

2020-01-15 Thread Sam Clegg via Phabricator via cfe-commits
sbc100 accepted this revision.
sbc100 added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:5589
+  // alias for "main" in the no-argument case so that libc can detect when
+  // new-style no-argument main is in used.
+  if (llvm::Function *F = getModule().getFunction("main")) {

Add a TODO to remove this once we remove the `__original_main` thing?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70700



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


Re: [clang] 23058f9 - [OPENMP]Do not use RTTI by default for NVPTX devices.

2020-01-15 Thread Artem Belevich via cfe-commits
On Wed, Jan 15, 2020 at 2:52 PM Alexey Bataev  wrote:

> 1. The problem is that it does not produce errors,
>
ATM, it does produce errors when it's disabled.

> it leads to the emission of some declaration that cannot be resolved by
> the linker. This what I was trying to avoid.
>
I'm OK with disabling it on device, but it should be done in a way to keep
RTTI in the host code working.

E.g. this code should compile: https://godbolt.org/z/Gzsrof
It still has your original change, so clang compilation fails. It does not
with NVCC.

2. Yes, I did not disable it on the host side, just for the device side. I
> disabled it only for NVPTX target, which is the device.
>
It's fine to disable it for code generated for the target. However, the
front-end needs to be able to deal with the host-side code where it is OK
to use RTTI.

--Artem




> -
> Best regards,
> Alexey Bataev
>
> 15.01.2020 12:49 PM, Artem Belevich пишет:
>
> Thank you.
>
> In general, RTTI should probably be treated similar to how we deal with
> inline assembly and ignore errors if they are in the code that we're not
> going to codegen during this side of compilation. E.g. during host-side
> compilation we don't complain about GPU-side registers in inline assembly
> that x86 target is not aware of.
>
> Disabling RTTI altogether on device side makes it impossible to use in any
> host-side CUDA because RTTI code will be seen by the device-side compiler,
> which will promptly fail, which is exactly what happened in this case --
> host-side template that relied on RTTI failed during device-side
> compilation:
>
>
> https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/arena.h#L536
> google/protobuf/arena.h:536:15: error: use of typeid requires -frtti
> AllocHook(RTTI_TYPE_ID(T), n);
> ...
> 2 errors generated when compiling for sm_60.
>
> --Artem
>
> On Wed, Jan 15, 2020 at 2:36 PM Alexey Bataev 
> wrote:
>
>> Sure, will revert it ASAP.
>>
>> -
>> Best regards,
>> Alexey Bataev
>>
>> 15.01.2020 12:26 PM, Artem Belevich пишет:
>>
>> Alexey,
>>
>> This breaks compilation of our cuda code which happens to transitively
>> include protobuf headers.
>> Can you, please, revert it for now until we figure out how RTTI should be
>> handled?
>>
>> --Artem
>>
>> On Tue, Jan 14, 2020 at 3:15 PM Alexey Bataev via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>>
>>> Author: Alexey Bataev
>>> Date: 2020-01-14T18:12:06-05:00
>>> New Revision: 23058f9dd4d7e18239fd63b6da52549514b45fda
>>>
>>> URL:
>>> https://github.com/llvm/llvm-project/commit/23058f9dd4d7e18239fd63b6da52549514b45fda
>>> DIFF:
>>> https://github.com/llvm/llvm-project/commit/23058f9dd4d7e18239fd63b6da52549514b45fda.diff
>>>
>>> LOG: [OPENMP]Do not use RTTI by default for NVPTX devices.
>>>
>>> NVPTX does not support RTTI, so disable it by default.
>>>
>>> Added:
>>> clang/test/Driver/openmp-offload-gpu.cpp
>>>
>>> Modified:
>>> clang/lib/Driver/ToolChain.cpp
>>>
>>> Removed:
>>>
>>>
>>>
>>>
>>> 
>>> diff  --git a/clang/lib/Driver/ToolChain.cpp
>>> b/clang/lib/Driver/ToolChain.cpp
>>> index cab97b1a601a..3ebbd30195b3 100644
>>> --- a/clang/lib/Driver/ToolChain.cpp
>>> +++ b/clang/lib/Driver/ToolChain.cpp
>>> @@ -68,7 +68,8 @@ static ToolChain::RTTIMode CalculateRTTIMode(const
>>> ArgList ,
>>>}
>>>
>>>// -frtti is default, except for the PS4 CPU.
>>> -  return (Triple.isPS4CPU()) ? ToolChain::RM_Disabled :
>>> ToolChain::RM_Enabled;
>>> +  return (Triple.isPS4CPU() || Triple.isNVPTX()) ?
>>> ToolChain::RM_Disabled
>>> + :
>>> ToolChain::RM_Enabled;
>>>  }
>>>
>>>  ToolChain::ToolChain(const Driver , const llvm::Triple ,
>>>
>>> diff  --git a/clang/test/Driver/openmp-offload-gpu.cpp
>>> b/clang/test/Driver/openmp-offload-gpu.cpp
>>> new file mode 100644
>>> index ..9da7308506ae
>>> --- /dev/null
>>> +++ b/clang/test/Driver/openmp-offload-gpu.cpp
>>> @@ -0,0 +1,20 @@
>>> +///
>>> +/// Perform several driver tests for OpenMP offloading
>>> +///
>>> +
>>> +// REQUIRES: clang-driver
>>> +// REQUIRES: x86-registered-target
>>> +// REQUIRES: powerpc-registered-target
>>> +// REQUIRES: nvptx-registered-target
>>> +
>>> +///
>>> ###
>>> +
>>> +/// PTXAS is passed -c flag by default when offloading to an NVIDIA
>>> device using OpenMP
>>> +/// Check that the flag is passed when -fopenmp-relocatable-target is
>>> used.
>>> +// RUN:   %clangxx -### -fopenmp=libomp
>>> -fopenmp-targets=nvptx64-nvidia-cuda \
>>> +// RUN:  -save-temps -no-canonical-prefixes %s -x c++ -c 2>&1 \
>>> +// RUN:   | FileCheck -check-prefix=CHK-RTTI %s
>>> +
>>> +// CHK-RTTI: clang{{.*}}" "-triple" "nvptx64-nvidia-cuda"
>>> +// CHK-RTTI-SAME: "-fno-rtti"
>>> +
>>>
>>>
>>>
>>> ___
>>> cfe-commits mailing list

[PATCH] D71082: Allow system header to provide their own implementation of some builtin

2020-01-15 Thread Amy Huang via Phabricator via cfe-commits
akhuang added a comment.

Reverted in 3d210ed3d1880c615776b07d1916edb400c245a6 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71082



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


[clang] 3d210ed - Revert "Allow system header to provide their own implementation of some builtin"

2020-01-15 Thread Amy Huang via cfe-commits

Author: Amy Huang
Date: 2020-01-15T15:03:45-08:00
New Revision: 3d210ed3d1880c615776b07d1916edb400c245a6

URL: 
https://github.com/llvm/llvm-project/commit/3d210ed3d1880c615776b07d1916edb400c245a6
DIFF: 
https://github.com/llvm/llvm-project/commit/3d210ed3d1880c615776b07d1916edb400c245a6.diff

LOG: Revert "Allow system header to provide their own implementation of some 
builtin"

This reverts commit 921f871ac438175ca8fcfcafdfcfac4d7ddf3905 because it
causes libc++ code to trigger __warn_memset_zero_len.

See https://reviews.llvm.org/D71082.

Added: 


Modified: 
clang/include/clang/AST/Decl.h
clang/lib/AST/Decl.cpp
clang/lib/CodeGen/CGExpr.cpp
clang/lib/CodeGen/CodeGenModule.cpp

Removed: 
clang/test/CodeGen/memcpy-nobuiltin.c
clang/test/CodeGen/memcpy-nobuiltin.inc



diff  --git a/clang/include/clang/AST/Decl.h b/clang/include/clang/AST/Decl.h
index 43c6c7b85db4..620ab4b089db 100644
--- a/clang/include/clang/AST/Decl.h
+++ b/clang/include/clang/AST/Decl.h
@@ -2309,9 +2309,6 @@ class FunctionDecl : public DeclaratorDecl,
   /// true through IsAligned.
   bool isReplaceableGlobalAllocationFunction(bool *IsAligned = nullptr) const;
 
-  /// Determine if this function provides an inline implementation of a 
builtin.
-  bool isInlineBuiltinDeclaration() const;
-
   /// Determine whether this is a destroying operator delete.
   bool isDestroyingOperatorDelete() const;
 

diff  --git a/clang/lib/AST/Decl.cpp b/clang/lib/AST/Decl.cpp
index 0d30f64b992e..be59d88b73f1 100644
--- a/clang/lib/AST/Decl.cpp
+++ b/clang/lib/AST/Decl.cpp
@@ -3046,14 +3046,6 @@ bool 
FunctionDecl::isReplaceableGlobalAllocationFunction(bool *IsAligned) const
   return Params == FPT->getNumParams();
 }
 
-bool FunctionDecl::isInlineBuiltinDeclaration() const {
-  if (!getBuiltinID())
-return false;
-
-  const FunctionDecl *Definition;
-  return hasBody(Definition) && Definition->isInlineSpecified();
-}
-
 bool FunctionDecl::isDestroyingOperatorDelete() const {
   // C++ P0722:
   //   Within a class C, a single object deallocation function with signature

diff  --git a/clang/lib/CodeGen/CGExpr.cpp b/clang/lib/CodeGen/CGExpr.cpp
index 8e0604181fb1..b23d9df5f4ba 100644
--- a/clang/lib/CodeGen/CGExpr.cpp
+++ b/clang/lib/CodeGen/CGExpr.cpp
@@ -4621,15 +4621,8 @@ RValue CodeGenFunction::EmitSimpleCallExpr(const 
CallExpr *E,
 }
 
 static CGCallee EmitDirectCallee(CodeGenFunction , const FunctionDecl *FD) 
{
-
   if (auto builtinID = FD->getBuiltinID()) {
-// Replaceable builtin provide their own implementation of a builtin. 
Unless
-// we are in the builtin implementation itself, don't call the actual
-// builtin. If we are in the builtin implementation, avoid trivial infinite
-// recursion.
-if (!FD->isInlineBuiltinDeclaration() ||
-CGF.CurFn->getName() == FD->getName())
-  return CGCallee::forBuiltin(builtinID, FD);
+return CGCallee::forBuiltin(builtinID, FD);
   }
 
   llvm::Constant *calleePtr = EmitFunctionDeclPointer(CGF.CGM, FD);

diff  --git a/clang/lib/CodeGen/CodeGenModule.cpp 
b/clang/lib/CodeGen/CodeGenModule.cpp
index 57beda26677c..038078bbe88d 100644
--- a/clang/lib/CodeGen/CodeGenModule.cpp
+++ b/clang/lib/CodeGen/CodeGenModule.cpp
@@ -1840,11 +1840,6 @@ void CodeGenModule::SetFunctionAttributes(GlobalDecl GD, 
llvm::Function *F,
   else if (const auto *SA = FD->getAttr())
  F->setSection(SA->getName());
 
-  if (FD->isInlineBuiltinDeclaration()) {
-F->addAttribute(llvm::AttributeList::FunctionIndex,
-llvm::Attribute::NoBuiltin);
-  }
-
   if (FD->isReplaceableGlobalAllocationFunction()) {
 // A replaceable global allocation function does not act like a builtin by
 // default, only if it is invoked by a new-expression or delete-expression.

diff  --git a/clang/test/CodeGen/memcpy-nobuiltin.c 
b/clang/test/CodeGen/memcpy-nobuiltin.c
deleted file mode 100644
index fb51d87413a1..
--- a/clang/test/CodeGen/memcpy-nobuiltin.c
+++ /dev/null
@@ -1,15 +0,0 @@
-// RUN: %clang_cc1 -verify -S -emit-llvm -o- %s -isystem %S -DWITH_DECL | 
FileCheck --check-prefix=CHECK-WITH-DECL %s
-// RUN: %clang_cc1 -verify -S -emit-llvm -o- %s -isystem %S -UWITH_DECL | 
FileCheck --check-prefix=CHECK-NO-DECL %s
-// RUN: %clang_cc1 -verify -S -emit-llvm -o- %s -isystem %S 
-DWITH_SELF_REFERENCE_DECL | FileCheck --check-prefix=CHECK-SELF-REF-DECL %s
-//
-// CHECK-WITH-DECL-NOT: @llvm.memcpy
-// CHECK-NO-DECL: @llvm.memcpy
-// CHECK-SELF-REF-DECL: @llvm.memcpy
-//
-#include 
-void test(void *dest, void const *from, size_t n) {
-  memcpy(dest, from, n);
-
-  static char buffer[1];
-  memcpy(buffer, from, 2); // expected-warning {{'memcpy' will always 
overflow; destination buffer has size 1, but size argument is 2}}
-}

diff  --git a/clang/test/CodeGen/memcpy-nobuiltin.inc 
b/clang/test/CodeGen/memcpy-nobuiltin.inc
deleted file mode 100644
index 

[PATCH] D50360: [Concepts] Requires Expressions

2020-01-15 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added inline comments.



Comment at: clang/include/clang/AST/ExprConcepts.h:144-148
+  struct SubstitutionDiagnostic {
+StringRef SubstitutedEntity;
+SourceLocation DiagLoc;
+StringRef DiagMessage;
+  };

Please add a FIXME to store the diagnostic semantically rather than as a 
pre-rendered string.



Comment at: clang/lib/Parse/ParseExprCXX.cpp:3345
+  ParseScope BodyScope(this, Scope::DeclScope);
+  RequiresExprBodyDecl *Body = Actions.ActOnEnterRequiresExpr(
+  RequiresKWLoc, LocalParameterDecls, getCurScope());

Please call these `ActOnStart...` and `ActOnFinish...` for consistency with 
other such functions in `Sema`.



Comment at: clang/lib/Parse/ParseExprCXX.cpp:3348
+
+  if (Tok.is(tok::r_brace))
+// Grammar does not allow an empty body.

This `if` body is long (even though it's just one statement); please add braces 
here.



Comment at: clang/lib/Parse/ParseExprCXX.cpp:3392
+if (!TryConsumeToken(tok::arrow))
+  // User probably forgot the arrow, remind him and try to continue
+  Diag(Tok, diag::err_requires_expr_missing_arrow)

him -> them, and please add a period.



Comment at: clang/lib/Parse/ParseExprCXX.cpp:3447
+  if (Res != TPResult::False) {
+// Skip to the closing parenthesis
+unsigned Depth = 1;

Please add a FIXME to avoid walking these tokens twice (once in 
`TryParseParameterDeclarationClause` and again here).



Comment at: clang/lib/Parse/ParseExprCXX.cpp:3504-3513
+  if (Tok.is(tok::annot_cxxscope)) {
+// The lack of typename might have prevented this from being
+// annotated as a type earlier.
+UnconsumeToken(TypenameKW);
+if (TryAnnotateTypeOrScopeToken()) {
+  SkipUntil(tok::semi, tok::r_brace,
+SkipUntilFlags::StopBeforeMatch);

Doing this by messing with the token stream and trying to perform annotation 
twice seems quite unclean, and you're doing too much of the semantic work of 
interpreting the typename requirement from inside the parser. Here's what I'd 
suggest:

First, call `TryAnnotateCXXScopeToken()`, which will annotate a scope and a 
following //template-id// (if any)

If we then have 
  * optionally, an `annot_cxxscope`, then
  * an `identifier` or an `annot_template_id`, then
  * a `semi` (or, not an `l_brace` nor an `l_paren`, depending on how you want 
to recover from errors)
then we have a //typename-requirement//. Call `Sema::ActOnTypeRequirement` and 
pass in the information you have (a scope and an identifier or template-id), 
and build a suitable type representation from `Sema`. (You might want to always 
build an `ElaboratedType` with `ETK_Typename`, even if the nested name 
specifier is non-dependent, to match the source syntax.)

And do this all in a tentative parse action, so you can revert it to put the 
`typename` keyword back when you find out that this is actually a 
//simple-requirement//.



Comment at: clang/lib/Parse/ParseExprCXX.cpp:3557
+  else
+Diag(Tok, 
diag::err_requires_expr_simple_requirement_unexpected_tok)
+<< Tok.getKind() << FixItHint::CreateInsertion(StartLoc, "{")

Is it useful to suggest a //compound-requirement// here? I expect this'll be 
hit a lot more for normal typos in the expression (eg, missing semicolon, 
forgotten operator, etc) than in cases where a compound-requirement was 
intended. `ExpectAndConsumeSemi` has various tricks to diagnose these cases 
well, and should be expected to gain more such tricks in the future; you should 
just call it here unless you're confident you know what the user did wrong (eg, 
in the `noexcept` case).



Comment at: clang/lib/Parse/ParseExprCXX.cpp:3574
+  // Don't emit an empty requires expr here to avoid confusing the user 
with
+  // other diagnostics quoting an empty requires expression he never wrote.
+  Braces.consumeClose();

he -> they



Comment at: clang/lib/Parse/ParseExprCXX.cpp:3582
+  Actions.ActOnExitRequiresExpr();
+  return Actions.CreateRequiresExpr(RequiresKWLoc, Body, LocalParameterDecls,
+Requirements, Braces.getCloseLocation());

This should be called `ActOn...` not `Create...`.



Comment at: clang/lib/Sema/SemaConcept.cpp:402
+  if (Req->isSubstitutionFailure()) {
+auto *SubstDiag = Req->getSubstitutionDiagnostic();
+if (!SubstDiag->DiagMessage.empty())

Please don't use `auto` here; the type is not clear from context.



Comment at: clang/lib/Sema/SemaConcept.cpp:964-968
+/*IsSatisfied=*/true // We reach this ctor with either 
dependent
+

[PATCH] D70700: [WebAssembly] Mangle the argc/argv `main` as `__main_argc_argv`

2020-01-15 Thread Dan Gohman via Phabricator via cfe-commits
sunfish added a comment.

@sbc100 Friendly ping :-).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70700



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


[PATCH] D72811: [WIP][OPENMP5.0] allow lvalue for motion clause

2020-01-15 Thread Chi Chun Chen via Phabricator via cfe-commits
cchen created this revision.
cchen added a reviewer: ABataev.
Herald added subscribers: cfe-commits, guansong.
Herald added a reviewer: jdoerfert.
Herald added a project: clang.

In OpenMP 5.0 we allow:

  int *p;
  
  int **p;
  
  struct S {
int struct *sp;
double *d;
struct S **sp_arr;
  };
  struct S *s;
  
  Now only add test for motion clause, after the implementation is fine,
  will add test for map since the core logic is in the same helper
  function.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D72811

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/lib/Sema/SemaOpenMP.cpp
  clang/test/OpenMP/target_map_messages.cpp
  clang/test/OpenMP/target_teams_map_messages.cpp
  clang/test/OpenMP/target_update_codegen.cpp
  clang/test/OpenMP/target_update_from_messages.cpp
  clang/test/OpenMP/target_update_to_messages.cpp

Index: clang/test/OpenMP/target_update_to_messages.cpp
===
--- clang/test/OpenMP/target_update_to_messages.cpp
+++ clang/test/OpenMP/target_update_to_messages.cpp
@@ -106,7 +106,7 @@
 
 #pragma omp target update to(x, a[:2]) // expected-error {{subscripted value is not an array or pointer}}
 #pragma omp target update to(x, c[:]) // expected-error {{subscripted value is not an array or pointer}}
-#pragma omp target update to(x, (m+1)[2]) // expected-error 2 {{expected expression containing only member accesses and/or array sections based on named variables}}
+#pragma omp target update to(x, (m+1)[2])
 #pragma omp target update to(s7.i, s7.a[:3])
 #pragma omp target update to(s7.s6[1].aa[0:5])
 #pragma omp target update to(x, s7.s6[:5].aa[6]) // expected-error {{OpenMP array section is not allowed here}}
@@ -159,7 +159,7 @@
 
 #pragma omp target update to(x, a[:2]) // expected-error {{subscripted value is not an array or pointer}}
 #pragma omp target update to(x, c[:]) // expected-error {{subscripted value is not an array or pointer}}
-#pragma omp target update to(x, (m+1)[2]) // expected-error {{expected expression containing only member accesses and/or array sections based on named variables}}
+#pragma omp target update to(x, (m+1)[2])
 #pragma omp target update to(s7.i, s7.a[:3])
 #pragma omp target update to(s7.s6[1].aa[0:5])
 #pragma omp target update to(x, s7.s6[:5].aa[6]) // expected-error {{OpenMP array section is not allowed here}}
Index: clang/test/OpenMP/target_update_from_messages.cpp
===
--- clang/test/OpenMP/target_update_from_messages.cpp
+++ clang/test/OpenMP/target_update_from_messages.cpp
@@ -106,7 +106,7 @@
 
 #pragma omp target update from(x, a[:2]) // expected-error {{subscripted value is not an array or pointer}}
 #pragma omp target update from(x, c[:]) // expected-error {{subscripted value is not an array or pointer}}
-#pragma omp target update from(x, (m+1)[2]) // expected-error 2 {{expected expression containing only member accesses and/or array sections based on named variables}}
+#pragma omp target update from(x, (m+1)[2])
 #pragma omp target update from(s7.i, s7.a[:3])
 #pragma omp target update from(s7.s6[1].aa[0:5])
 #pragma omp target update from(x, s7.s6[:5].aa[6]) // expected-error {{OpenMP array section is not allowed here}}
@@ -160,7 +160,7 @@
 
 #pragma omp target update from(x, a[:2]) // expected-error {{subscripted value is not an array or pointer}}
 #pragma omp target update from(x, c[:]) // expected-error {{subscripted value is not an array or pointer}}
-#pragma omp target update from(x, (m+1)[2]) // expected-error {{expected expression containing only member accesses and/or array sections based on named variables}}
+#pragma omp target update from(x, (m+1)[2])
 #pragma omp target update from(s7.i, s7.a[:3])
 #pragma omp target update from(s7.s6[1].aa[0:5])
 #pragma omp target update from(x, s7.s6[:5].aa[6]) // expected-error {{OpenMP array section is not allowed here}}
Index: clang/test/OpenMP/target_update_codegen.cpp
===
--- clang/test/OpenMP/target_update_codegen.cpp
+++ clang/test/OpenMP/target_update_codegen.cpp
@@ -291,5 +291,405 @@
   #pragma omp target update from(arg) if(arg) device(4)
   {++arg;}
 }
+#endif
+///==///
+// RUN: %clang_cc1 -DCK5 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck %s --check-prefix CK5 --check-prefix CK5-64
+// RUN: %clang_cc1 -DCK5 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s  --check-prefix CK5 --check-prefix CK5-64
+// RUN: %clang_cc1 -DCK5 -verify -fopenmp 

Re: [clang] 23058f9 - [OPENMP]Do not use RTTI by default for NVPTX devices.

2020-01-15 Thread Artem Belevich via cfe-commits
Thank you.

In general, RTTI should probably be treated similar to how we deal with
inline assembly and ignore errors if they are in the code that we're not
going to codegen during this side of compilation. E.g. during host-side
compilation we don't complain about GPU-side registers in inline assembly
that x86 target is not aware of.

Disabling RTTI altogether on device side makes it impossible to use in any
host-side CUDA because RTTI code will be seen by the device-side compiler,
which will promptly fail, which is exactly what happened in this case --
host-side template that relied on RTTI failed during device-side
compilation:

https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/arena.h#L536
google/protobuf/arena.h:536:15: error: use of typeid requires -frtti
AllocHook(RTTI_TYPE_ID(T), n);
...
2 errors generated when compiling for sm_60.

--Artem

On Wed, Jan 15, 2020 at 2:36 PM Alexey Bataev  wrote:

> Sure, will revert it ASAP.
>
> -
> Best regards,
> Alexey Bataev
>
> 15.01.2020 12:26 PM, Artem Belevich пишет:
>
> Alexey,
>
> This breaks compilation of our cuda code which happens to transitively
> include protobuf headers.
> Can you, please, revert it for now until we figure out how RTTI should be
> handled?
>
> --Artem
>
> On Tue, Jan 14, 2020 at 3:15 PM Alexey Bataev via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>>
>> Author: Alexey Bataev
>> Date: 2020-01-14T18:12:06-05:00
>> New Revision: 23058f9dd4d7e18239fd63b6da52549514b45fda
>>
>> URL:
>> https://github.com/llvm/llvm-project/commit/23058f9dd4d7e18239fd63b6da52549514b45fda
>> DIFF:
>> https://github.com/llvm/llvm-project/commit/23058f9dd4d7e18239fd63b6da52549514b45fda.diff
>>
>> LOG: [OPENMP]Do not use RTTI by default for NVPTX devices.
>>
>> NVPTX does not support RTTI, so disable it by default.
>>
>> Added:
>> clang/test/Driver/openmp-offload-gpu.cpp
>>
>> Modified:
>> clang/lib/Driver/ToolChain.cpp
>>
>> Removed:
>>
>>
>>
>>
>> 
>> diff  --git a/clang/lib/Driver/ToolChain.cpp
>> b/clang/lib/Driver/ToolChain.cpp
>> index cab97b1a601a..3ebbd30195b3 100644
>> --- a/clang/lib/Driver/ToolChain.cpp
>> +++ b/clang/lib/Driver/ToolChain.cpp
>> @@ -68,7 +68,8 @@ static ToolChain::RTTIMode CalculateRTTIMode(const
>> ArgList ,
>>}
>>
>>// -frtti is default, except for the PS4 CPU.
>> -  return (Triple.isPS4CPU()) ? ToolChain::RM_Disabled :
>> ToolChain::RM_Enabled;
>> +  return (Triple.isPS4CPU() || Triple.isNVPTX()) ? ToolChain::RM_Disabled
>> + : ToolChain::RM_Enabled;
>>  }
>>
>>  ToolChain::ToolChain(const Driver , const llvm::Triple ,
>>
>> diff  --git a/clang/test/Driver/openmp-offload-gpu.cpp
>> b/clang/test/Driver/openmp-offload-gpu.cpp
>> new file mode 100644
>> index ..9da7308506ae
>> --- /dev/null
>> +++ b/clang/test/Driver/openmp-offload-gpu.cpp
>> @@ -0,0 +1,20 @@
>> +///
>> +/// Perform several driver tests for OpenMP offloading
>> +///
>> +
>> +// REQUIRES: clang-driver
>> +// REQUIRES: x86-registered-target
>> +// REQUIRES: powerpc-registered-target
>> +// REQUIRES: nvptx-registered-target
>> +
>> +///
>> ###
>> +
>> +/// PTXAS is passed -c flag by default when offloading to an NVIDIA
>> device using OpenMP
>> +/// Check that the flag is passed when -fopenmp-relocatable-target is
>> used.
>> +// RUN:   %clangxx -### -fopenmp=libomp
>> -fopenmp-targets=nvptx64-nvidia-cuda \
>> +// RUN:  -save-temps -no-canonical-prefixes %s -x c++ -c 2>&1 \
>> +// RUN:   | FileCheck -check-prefix=CHK-RTTI %s
>> +
>> +// CHK-RTTI: clang{{.*}}" "-triple" "nvptx64-nvidia-cuda"
>> +// CHK-RTTI-SAME: "-fno-rtti"
>> +
>>
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
>
> --
> --Artem Belevich
>
>

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


[PATCH] D72380: [DataFlow] Factor two worklist implementations out

2020-01-15 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added a comment.

I'm excited about this effort!~

The change in uninitialized values analysis gives me a bit of anxiety. Could 
you explain what exactly has changed that caused the change in the stats and 
why you think it doesn't make a difference, maybe give an example? (an example 
could be obtained by `creduce`-ing over "the stats have changed" criterion)


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

https://reviews.llvm.org/D72380



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


[clang] 6b29aa2 - Revert "[OPENMP]Do not use RTTI by default for NVPTX devices."

2020-01-15 Thread Alexey Bataev via cfe-commits

Author: Alexey Bataev
Date: 2020-01-15T17:42:26-05:00
New Revision: 6b29aa21180cf14bfb619d38fc4826913cabfb66

URL: 
https://github.com/llvm/llvm-project/commit/6b29aa21180cf14bfb619d38fc4826913cabfb66
DIFF: 
https://github.com/llvm/llvm-project/commit/6b29aa21180cf14bfb619d38fc4826913cabfb66.diff

LOG: Revert "[OPENMP]Do not use RTTI by default for NVPTX devices."

This reverts commit 23058f9dd4d7e18239fd63b6da52549514b45fda. It breaks
builds of cuda code somehow in some cases.

Added: 


Modified: 
clang/lib/Driver/ToolChain.cpp

Removed: 
clang/test/Driver/openmp-offload-gpu.cpp



diff  --git a/clang/lib/Driver/ToolChain.cpp b/clang/lib/Driver/ToolChain.cpp
index 3ebbd30195b3..cab97b1a601a 100644
--- a/clang/lib/Driver/ToolChain.cpp
+++ b/clang/lib/Driver/ToolChain.cpp
@@ -68,8 +68,7 @@ static ToolChain::RTTIMode CalculateRTTIMode(const ArgList 
,
   }
 
   // -frtti is default, except for the PS4 CPU.
-  return (Triple.isPS4CPU() || Triple.isNVPTX()) ? ToolChain::RM_Disabled
- : ToolChain::RM_Enabled;
+  return (Triple.isPS4CPU()) ? ToolChain::RM_Disabled : ToolChain::RM_Enabled;
 }
 
 ToolChain::ToolChain(const Driver , const llvm::Triple ,

diff  --git a/clang/test/Driver/openmp-offload-gpu.cpp 
b/clang/test/Driver/openmp-offload-gpu.cpp
deleted file mode 100644
index 9da7308506ae..
--- a/clang/test/Driver/openmp-offload-gpu.cpp
+++ /dev/null
@@ -1,20 +0,0 @@
-///
-/// Perform several driver tests for OpenMP offloading
-///
-
-// REQUIRES: clang-driver
-// REQUIRES: x86-registered-target
-// REQUIRES: powerpc-registered-target
-// REQUIRES: nvptx-registered-target
-
-/// ###
-
-/// PTXAS is passed -c flag by default when offloading to an NVIDIA device 
using OpenMP
-/// Check that the flag is passed when -fopenmp-relocatable-target is used.
-// RUN:   %clangxx -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda \
-// RUN:  -save-temps -no-canonical-prefixes %s -x c++ -c 2>&1 \
-// RUN:   | FileCheck -check-prefix=CHK-RTTI %s
-
-// CHK-RTTI: clang{{.*}}" "-triple" "nvptx64-nvidia-cuda"
-// CHK-RTTI-SAME: "-fno-rtti"
-



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


[PATCH] D71082: Allow system header to provide their own implementation of some builtin

2020-01-15 Thread Amy Huang via Phabricator via cfe-commits
akhuang added a comment.

This caused a linker error in chromium:

  ld.lld: error: undefined symbol: __warn_memset_zero_len

Apparently now that the glibc memset is being used, __warn_memset_zero_len gets 
called from libc++ code 
(https://github.com/llvm/llvm-project/blob/b72a8c65e4e34779b6bc9e466203f553f5294486/libcxx/include/__bit_reference#L371).

A repro:

  $ cat t.cpp
  #include 
  void useit(std::bitset<3> );
  std::bitset<3> getit();
  int main() {
std::bitset<3> bits = getit();
bits.set();
useit(bits);
  }
  
  $ clang -S -O2 t.cpp  -o - -stdlib=libc++ -D_FORTIFY_SOURCE=1 | grep warn_mem
  callq   __warn_memset_zero_len


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71082



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


Re: [clang] 23058f9 - [OPENMP]Do not use RTTI by default for NVPTX devices.

2020-01-15 Thread Artem Belevich via cfe-commits
Alexey,

This breaks compilation of our cuda code which happens to transitively
include protobuf headers.
Can you, please, revert it for now until we figure out how RTTI should be
handled?

--Artem

On Tue, Jan 14, 2020 at 3:15 PM Alexey Bataev via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
> Author: Alexey Bataev
> Date: 2020-01-14T18:12:06-05:00
> New Revision: 23058f9dd4d7e18239fd63b6da52549514b45fda
>
> URL:
> https://github.com/llvm/llvm-project/commit/23058f9dd4d7e18239fd63b6da52549514b45fda
> DIFF:
> https://github.com/llvm/llvm-project/commit/23058f9dd4d7e18239fd63b6da52549514b45fda.diff
>
> LOG: [OPENMP]Do not use RTTI by default for NVPTX devices.
>
> NVPTX does not support RTTI, so disable it by default.
>
> Added:
> clang/test/Driver/openmp-offload-gpu.cpp
>
> Modified:
> clang/lib/Driver/ToolChain.cpp
>
> Removed:
>
>
>
>
> 
> diff  --git a/clang/lib/Driver/ToolChain.cpp
> b/clang/lib/Driver/ToolChain.cpp
> index cab97b1a601a..3ebbd30195b3 100644
> --- a/clang/lib/Driver/ToolChain.cpp
> +++ b/clang/lib/Driver/ToolChain.cpp
> @@ -68,7 +68,8 @@ static ToolChain::RTTIMode CalculateRTTIMode(const
> ArgList ,
>}
>
>// -frtti is default, except for the PS4 CPU.
> -  return (Triple.isPS4CPU()) ? ToolChain::RM_Disabled :
> ToolChain::RM_Enabled;
> +  return (Triple.isPS4CPU() || Triple.isNVPTX()) ? ToolChain::RM_Disabled
> + : ToolChain::RM_Enabled;
>  }
>
>  ToolChain::ToolChain(const Driver , const llvm::Triple ,
>
> diff  --git a/clang/test/Driver/openmp-offload-gpu.cpp
> b/clang/test/Driver/openmp-offload-gpu.cpp
> new file mode 100644
> index ..9da7308506ae
> --- /dev/null
> +++ b/clang/test/Driver/openmp-offload-gpu.cpp
> @@ -0,0 +1,20 @@
> +///
> +/// Perform several driver tests for OpenMP offloading
> +///
> +
> +// REQUIRES: clang-driver
> +// REQUIRES: x86-registered-target
> +// REQUIRES: powerpc-registered-target
> +// REQUIRES: nvptx-registered-target
> +
> +///
> ###
> +
> +/// PTXAS is passed -c flag by default when offloading to an NVIDIA
> device using OpenMP
> +/// Check that the flag is passed when -fopenmp-relocatable-target is
> used.
> +// RUN:   %clangxx -### -fopenmp=libomp
> -fopenmp-targets=nvptx64-nvidia-cuda \
> +// RUN:  -save-temps -no-canonical-prefixes %s -x c++ -c 2>&1 \
> +// RUN:   | FileCheck -check-prefix=CHK-RTTI %s
> +
> +// CHK-RTTI: clang{{.*}}" "-triple" "nvptx64-nvidia-cuda"
> +// CHK-RTTI-SAME: "-fno-rtti"
> +
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>


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


[PATCH] D72810: [LifetimeAnalysis] Add support for lifetime annotations on functions

2020-01-15 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun created this revision.
xazax.hun added reviewers: mgehre, ymandel, gribozavr2, aaron.ballman, rsmith, 
rjmccall.
xazax.hun added a project: clang.
Herald added subscribers: Szelethus, Charusso, gamesh411, dkrupp, rnkovacs, 
mgorny.

This patch corresponds to this RFC: 
http://lists.llvm.org/pipermail/cfe-dev/2019-December/064067.html

This does not cover everything yet, but I wanted to keep the patch small to be 
incremental.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D72810

Files:
  clang/include/clang/AST/Attr.h
  clang/include/clang/AST/LifetimeAttr.h
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/AST/CMakeLists.txt
  clang/lib/AST/LifetimeAttr.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaInit.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/Sema/attr-psets-annotation.cpp

Index: clang/test/Sema/attr-psets-annotation.cpp
===
--- /dev/null
+++ clang/test/Sema/attr-psets-annotation.cpp
@@ -0,0 +1,134 @@
+// RUN: %clang_cc1 -fsyntax-only -Wlifetime -Wlifetime-dump-contracts -verify %s
+
+namespace gsl {
+struct null_t {
+  template 
+  operator T() const;
+} Null;
+struct static_t {
+  template 
+  operator T() const;
+} Static;
+struct invalid_t {
+  template 
+  operator T() const;
+} Invalid;
+
+struct return_t {
+  template 
+  operator T() const;
+} Return;
+
+template 
+struct PointerTraits {
+  static auto deref(const T ) -> decltype(*t);
+};
+
+template 
+struct PointerTraits {
+  static const T (const T *t);
+};
+
+template 
+struct PointerTraits {
+  static const T (const T );
+};
+
+struct PSet {
+  PSet(...);
+};
+
+template 
+auto deref(const T ) -> decltype(PointerTraits::deref(t));
+
+template 
+bool lifetime(const T , const PSet );
+} // namespace gsl
+
+using namespace gsl;
+
+void basic(int *a, int *b) [[gsl::pre(lifetime(b, {a}))]];
+// expected-warning@-1 {{Pre { b -> { a }; }}}
+
+void specials(int *a, int *b, int *c)
+[[gsl::pre(lifetime(a, {Null}))]]
+[[gsl::pre(lifetime(b, {Static}))]]
+[[gsl::pre(lifetime(c, {Invalid}))]];
+// expected-warning@-4 {{Pre { a -> { Null }; b -> { Static }; c -> { Invalid }; }}}
+
+void variadic(int *a, int *b, int *c)
+[[gsl::pre(lifetime(b, {a, c}))]];
+// expected-warning@-2 {{Pre { b -> { a c }; }}}
+
+void variadic_special(int *a, int *b, int *c)
+[[gsl::pre(lifetime(b, {a, Null}))]];
+// expected-warning@-2 {{Pre { b -> { Null a }; }}}
+
+void multiple_annotations(int *a, int *b, int *c)
+[[gsl::pre(lifetime(b, {a}))]]
+[[gsl::pre(lifetime(c, {a}))]];
+// expected-warning@-3 {{Pre { b -> { a }; c -> { a }; }}}
+
+void multiple_annotations_chained(int *a, int *b, int *c)
+[[gsl::pre(lifetime(b, {a}))]]
+[[gsl::pre(lifetime(c, {b}))]];
+// expected-warning@-3 {{Pre { b -> { a }; c -> { a }; }}}
+
+void deref_ptr(int *a, int *b, int **c)
+[[gsl::pre(lifetime(deref(c), {a}))]];
+// expected-warning@-2 {{Pre { *c -> { a }; }}}
+
+void deref_ptr_pointee(int *a, int *b, int **c)
+[[gsl::pre(lifetime(a, {deref(c)}))]];
+// expected-warning@-2 {{Pre { a -> { *c }; }}}
+
+void deref_ref(int *a, int *b, int *)
+[[gsl::pre(lifetime(deref(c), {a}))]];
+// expected-warning@-2 {{Pre { *c -> { a }; }}}
+
+void deref_ref_pointee(int *a, int *b, int *)
+[[gsl::pre(lifetime(a, {deref(c)}))]];
+// expected-warning@-2 {{Pre { a -> { *c }; }}}
+
+struct [[gsl::Owner(void)]] X {
+  void f(X **out)
+  [[gsl::post(lifetime(deref(out), {this}))]];
+  // expected-warning@-2 {{Pre { }  Post { *out -> { this }; }}}
+  X *operator+(const X& other)
+  [[gsl::post(lifetime(Return, {other}))]];
+  // expected-warning@-2 {{Pre { }  Post { (return value) -> { other }; }}}
+};
+
+template 
+It find(It begin, It end, const T )
+[[gsl::pre(lifetime(end, {begin}))]]
+[[gsl::post(lifetime(Return, {begin}))]];
+// expected-warning@-3 {{Pre { end -> { begin }; }  Post { (return value) -> { begin }; }}}
+
+int *find_nontemp(int *begin, int *end, const int )
+[[gsl::pre(lifetime(end, {begin}))]]
+[[gsl::post(lifetime(Return, {begin}))]];
+// expected-warning@-3 {{Pre { end -> { begin }; }  Post { (return value) -> { begin }; }}}
+
+struct [[gsl::Owner(int)]] MyOwner {
+  int *begin()
+  [[gsl::post(lifetime(Return, {this}))]];
+  // expected-warning@-2 {{Pre { }  Post { (return value) -> { this }; }}}
+  int *end()
+  [[gsl::post(lifetime(Return, {this}))]];
+  // expected-warning@-2 {{Pre { }  Post { (return value) -> { this }; }}}
+};
+
+void testGslWarning() {
+  int *res = find(MyOwner{}.begin(), MyOwner{}.end(), 5);
+  // expected-warning@-1 {{object backing the pointer will be destroyed at the end of the full-expression}}
+  (void)res;
+  int *res2 = find_nontemp(MyOwner{}.begin(), MyOwner{}.end(), 5);
+  // expected-warning@-1 {{object backing the pointer will be destroyed at the end of the 

[PATCH] D70926: [clang-format] Add option for not breaking line before ObjC params

2020-01-15 Thread Kanglei Fang via Phabricator via cfe-commits
ghvg1313 added a comment.

@MyDeveloperDay gentle ping for help merging


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70926



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


[PATCH] D50360: [Concepts] Requires Expressions

2020-01-15 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added inline comments.



Comment at: clang/lib/AST/StmtPrinter.cpp:2296
+  S.flush();
+  if (Buf.find("typename ") != 0)
+OS << "typename ";

I can see why this is the most straightforward way to implement this, but ... 
yuck. Please add a FIXME :)



Comment at: clang/lib/AST/StmtProfile.cpp:1363
+  //expression. It is equivalent to the simple-requirement x++; [...]
+  // We therefore do not profile isSimple() here.
+  ID.AddBoolean(ExprReq->getNoexceptLoc().isValid());

This means "equivalent to" in the plain English sense, not in the 
[temp.over.link] sense, and in any case is not normative. The normative rule is 
the one in [temp.over.link] based on the ODR / token sequence. It'd be fine to 
profile `isSimple()` if you want to. (But it's not necessary since a `{ expr 
};` requirement is functionally equivalent to a `expr;` requirement.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D50360



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


[PATCH] D72742: Don't assume promotable integers are zero/sign-extended already in x86-64 ABI.

2020-01-15 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added a comment.

In D72742#1822709 , @emilio wrote:

> GCC does avoid the zero-extension on the caller sometimes, when not required 
> by the language and when its optimizer finds it suitable.


I believe at the time, faced with ambiguity in the document, experiments were 
done to try to uncover what GCC actually did in practice. I guess LLVM settled 
on the "things are extended to 32-bits" model.

This change seems like it has backwards compatibility concerns with clang. If 
new clang stops extending things and it calls old clang code, won't that cause 
breakages? Based on the test code updates, it seems like you are updating both 
call sites and function prototypes. Won't that be problematic for the users 
that care about ABI stability over GCC ABI compatibility?




Comment at: clang/test/CodeGen/2007-06-18-SextAttrAggregate.c:11
 
+// Same for AMD64's PSABI
+

This test was originally added for x86_64, see the bug:
https://bugs.llvm.org/show_bug.cgi?id=1513

It needs to be updated.



Comment at: clang/test/CodeGenCXX/const-init-cxx11.cpp:536
   void test() {
-// CHECK: call void @_ZN13InitFromConst7consumeIbEEvT_(i1 zeroext true)
+// FIXME: This should probably be:
+// call void @_ZN13InitFromConst7consumeIbEEvT_(i1 zeroext true)

I agree it would be nice to avoid emitting these coercions through memory for 
such simple cases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72742



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


[PATCH] D72612: [AArch64][SVE] Add ImmArg property to intrinsics with immediates

2020-01-15 Thread Eli Friedman via Phabricator via cfe-commits
efriedma accepted this revision.
efriedma added a comment.
This revision is now accepted and ready to land.

LGTM with one question




Comment at: llvm/lib/Target/AArch64/AArch64InstrFormats.td:1108
+  def "" : AsmVectorIndexOpnd, PatLeaf<(ty imm), pred>;
+  def _timm : AsmVectorIndexOpnd, PatLeaf<(ty timm), pred>;
+}

Using ImmLeaf/TImmLeaf doesn't work here?


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

https://reviews.llvm.org/D72612



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


[PATCH] D50360: [Concepts] Requires Expressions

2020-01-15 Thread Saar Raz via Phabricator via cfe-commits
saar.raz marked 4 inline comments as done.
saar.raz added a comment.

Addressed comments in latest diff.




Comment at: clang/include/clang/AST/RecursiveASTVisitor.h:2714-2716
+  if (RetReq.isTypeConstraint())
+TRY_TO(TraverseTemplateParameterListHelper(
+   RetReq.getTypeConstraintTemplateParameterList()));

rsmith wrote:
> We should traverse the entire //type-constraint// here, including the nested 
> name specifier and concept name.
We are traversing all that down the line when traversing the actual template 
type parameter.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D50360



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


[PATCH] D72806: [HIP] fix paths for executables not in clang bin directory

2020-01-15 Thread Holger Wünsche via Phabricator via cfe-commits
DieGoldeneEnte created this revision.
DieGoldeneEnte added a reviewer: yaxunl.
Herald added subscribers: cfe-commits, mgorny.
Herald added a project: clang.

The previous code constructed the executable paths for llvm-link, opt, lld, llc 
and clang-offload-bundler for the path to the compiler. This change uses cmake 
to find the directory containing llvm and lld and searches them using the 
GetProgramPath method in addition to the compiler directory.

The test completed without error (except one which failed even without my 
patch) and I was able to confirm successful compilation using the hip toolchain 
by compiling a simple program with clang, lld, and llvm executables in 
different directories.


Repository:
  rC Clang

https://reviews.llvm.org/D72806

Files:
  clang/CMakeLists.txt
  clang/lib/Driver/ToolChains/HIP.cpp

Index: clang/lib/Driver/ToolChains/HIP.cpp
===
--- clang/lib/Driver/ToolChains/HIP.cpp
+++ clang/lib/Driver/ToolChains/HIP.cpp
@@ -105,9 +105,8 @@
   CmdArgs.push_back("-o");
   auto OutputFileName = getOutputFileName(C, OutputFilePrefix, "-linked", "bc");
   CmdArgs.push_back(OutputFileName);
-  SmallString<128> ExecPath(C.getDriver().Dir);
-  llvm::sys::path::append(ExecPath, "llvm-link");
-  const char *Exec = Args.MakeArgString(ExecPath);
+  const char *Exec =
+  Args.MakeArgString(getToolChain().GetProgramPath("llvm-link"));
   C.addCommand(std::make_unique(JA, *this, Exec, CmdArgs, Inputs));
   return OutputFileName;
 }
@@ -133,9 +132,8 @@
   auto OutputFileName =
   getOutputFileName(C, OutputFilePrefix, "-optimized", "bc");
   OptArgs.push_back(OutputFileName);
-  SmallString<128> OptPath(C.getDriver().Dir);
-  llvm::sys::path::append(OptPath, "opt");
-  const char *OptExec = Args.MakeArgString(OptPath);
+  const char *OptExec =
+  Args.MakeArgString(getToolChain().GetProgramPath("opt"));
   C.addCommand(std::make_unique(JA, *this, OptExec, OptArgs, Inputs));
   return OutputFileName;
 }
@@ -180,9 +178,7 @@
   auto LlcOutputFile =
   getOutputFileName(C, OutputFilePrefix, "", OutputIsAsm ? "s" : "o");
   LlcArgs.push_back(LlcOutputFile);
-  SmallString<128> LlcPath(C.getDriver().Dir);
-  llvm::sys::path::append(LlcPath, "llc");
-  const char *Llc = Args.MakeArgString(LlcPath);
+  const char *Llc = Args.MakeArgString(getToolChain().GetProgramPath("llc"));
   C.addCommand(std::make_unique(JA, *this, Llc, LlcArgs, Inputs));
   return LlcOutputFile;
 }
@@ -196,9 +192,7 @@
   // The output from ld.lld is an HSA code object file.
   ArgStringList LldArgs{
   "-flavor", "gnu", "-shared", "-o", Output.getFilename(), InputFileName};
-  SmallString<128> LldPath(C.getDriver().Dir);
-  llvm::sys::path::append(LldPath, "lld");
-  const char *Lld = Args.MakeArgString(LldPath);
+  const char *Lld = Args.MakeArgString(getToolChain().GetProgramPath("lld"));
   C.addCommand(std::make_unique(JA, *this, Lld, LldArgs, Inputs));
 }
 
@@ -230,9 +224,8 @@
   Args.MakeArgString(std::string("-outputs=").append(OutputFileName));
   BundlerArgs.push_back(BundlerOutputArg);
 
-  SmallString<128> BundlerPath(C.getDriver().Dir);
-  llvm::sys::path::append(BundlerPath, "clang-offload-bundler");
-  const char *Bundler = Args.MakeArgString(BundlerPath);
+  const char *Bundler = Args.MakeArgString(
+  T.getToolChain().GetProgramPath("clang-offload-bundler"));
   C.addCommand(std::make_unique(JA, T, Bundler, BundlerArgs, Inputs));
 }
 
@@ -277,6 +270,16 @@
   // Lookup binaries into the driver directory, this is used to
   // discover the clang-offload-bundler executable.
   getProgramPaths().push_back(getDriver().Dir);
+
+// add llvm binaries in case they are not in the driver directory
+#if defined(LLVM_TOOLS_BINARY_DIR)
+  getProgramPaths().push_back(LLVM_TOOLS_BINARY_DIR);
+#endif
+
+// add lld binary in case they are not in the driver directory
+#if defined(LLD_BINARY_DIR)
+  getProgramPaths().push_back(LLD_BINARY_DIR);
+#endif
 }
 
 void HIPToolChain::addClangTargetOptions(
Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -866,6 +866,22 @@
   llvm_distribution_add_targets()
 endif()
 
+# add LLVM_TOOLS_BINARY_DIR to Defines to make llc, llvm-link and opt available
+# for HIP toolchain
+add_definitions( -DLLVM_TOOLS_BINARY_DIR="${TOOLS_BINARY_DIR} " )
+message(STATUS "found llvm executable dir: ${TOOLS_BINARY_DIR}")
+
+# add LLD_BINARY_DIR to Defines to make lld available for HIP toolchain
+find_program(LLD_BINARY NAMES lld)
+if(LLD_BINARY MATCHES "-NOTFOUND")
+  message(SEND_ERROR "Could not find lld executable")
+else()
+  message(STATUS "found lld executable: ${LLD_BINARY}")
+endif()
+get_filename_component(LLD_BINARY_DIR ${LLD_BINARY} DIRECTORY)
+add_definitions( -DLLD_BINARY_DIR="${LLD_BINARY_DIR} " )
+
+
 configure_file(
   ${CLANG_SOURCE_DIR}/include/clang/Config/config.h.cmake
   

[PATCH] D72547: [llvm] Make new pass manager's OptimizationLevel a class

2020-01-15 Thread Mircea Trofin via Phabricator via cfe-commits
mtrofin updated this revision to Diff 238352.
mtrofin marked 4 inline comments as done.
mtrofin added a comment.
Herald added a subscriber: zzheng.

Incorporated feedback:

- tests
- updated patch description


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72547

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  llvm/include/llvm/Passes/PassBuilder.h
  llvm/lib/LTO/LTOBackend.cpp
  llvm/lib/Passes/PassBuilder.cpp
  llvm/lib/Transforms/Scalar/LoopUnrollPass.cpp
  llvm/test/Transforms/LoopUnroll/opt-levels.ll
  llvm/test/Transforms/LoopUnrollAndJam/opt-levels.ll

Index: llvm/test/Transforms/LoopUnrollAndJam/opt-levels.ll
===
--- /dev/null
+++ llvm/test/Transforms/LoopUnrollAndJam/opt-levels.ll
@@ -0,0 +1,61 @@
+; RUN: opt < %s -S -passes="default" -unroll-runtime=true -enable-npm-unroll-and-jam -unroll-threshold-default=0 -unroll-threshold-aggressive=300 | FileCheck %s -check-prefix=O2
+; RUN: opt < %s -S -passes="default" -unroll-runtime=true -enable-npm-unroll-and-jam -unroll-threshold-default=0 -unroll-threshold-aggressive=300 | FileCheck %s -check-prefix=O3
+; RUN: opt < %s -S -passes="default" -unroll-runtime=true -enable-npm-unroll-and-jam -unroll-threshold-default=0 -unroll-threshold-aggressive=300 | FileCheck %s -check-prefix=Os
+; RUN: opt < %s -S -passes="default" -unroll-runtime=true -enable-npm-unroll-and-jam -unroll-threshold-default=0 -unroll-threshold-aggressive=300 | FileCheck %s -check-prefix=Oz
+
+; Check that Os and Oz are optimized like O2, not like O3. To easily highlight
+; the behavior, we artificially disable unrolling for anything but O3 by setting
+; the default threshold to 0.
+
+; O3: for.inner.1
+; O2-NOT: for.inner.1
+; Os-NOT: for.inner.1
+; Oz-NOT: for.inner.1
+
+target datalayout = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
+
+define void @test1(i32 %I, i32 %J, i32* noalias nocapture %A, i32* noalias nocapture readonly %B) #0 {
+entry:
+  %cmp = icmp ne i32 %J, 0
+  %cmpJ = icmp ne i32 %I, 0
+  %or.cond = and i1 %cmp, %cmpJ
+  br i1 %or.cond, label %for.outer.preheader, label %for.end
+
+for.outer.preheader:
+  br label %for.outer
+
+for.outer:
+  %i = phi i32 [ %add8, %for.latch ], [ 0, %for.outer.preheader ]
+  br label %for.inner
+
+for.inner:
+  %j = phi i32 [ 0, %for.outer ], [ %inc, %for.inner ]
+  %sum = phi i32 [ 0, %for.outer ], [ %add, %for.inner ]
+  %arrayidx = getelementptr inbounds i32, i32* %B, i32 %j
+  %0 = load i32, i32* %arrayidx, align 4, !tbaa !5
+  %add = add i32 %0, %sum
+  %inc = add nuw i32 %j, 1
+  %exitcond = icmp eq i32 %inc, %J
+  br i1 %exitcond, label %for.latch, label %for.inner
+
+for.latch:
+  %add.lcssa = phi i32 [ %add, %for.inner ]
+  %arrayidx6 = getelementptr inbounds i32, i32* %A, i32 %i
+  store i32 %add.lcssa, i32* %arrayidx6, align 4, !tbaa !5
+  %add8 = add nuw i32 %i, 1
+  %exitcond25 = icmp eq i32 %add8, %I
+  br i1 %exitcond25, label %for.end.loopexit, label %for.outer
+
+for.end.loopexit:
+  br label %for.end
+
+for.end:
+  ret void
+}
+
+
+
+!5 = !{!6, !6, i64 0}
+!6 = !{!"int", !7, i64 0}
+!7 = !{!"omnipotent char", !8, i64 0}
+!8 = !{!"Simple C/C++ TBAA"}
Index: llvm/test/Transforms/LoopUnroll/opt-levels.ll
===
--- /dev/null
+++ llvm/test/Transforms/LoopUnroll/opt-levels.ll
@@ -0,0 +1,47 @@
+; RUN: opt < %s -S -passes="default" -unroll-runtime=true -unroll-threshold-default=0 -unroll-threshold-aggressive=300 | FileCheck %s -check-prefix=O2
+; RUN: opt < %s -S -passes="default" -unroll-runtime=true -unroll-threshold-default=0 -unroll-threshold-aggressive=300 | FileCheck %s -check-prefix=O3
+; RUN: opt < %s -S -passes="default" -unroll-runtime=true -unroll-threshold-default=0 -unroll-threshold-aggressive=300 | FileCheck %s -check-prefix=Os
+; RUN: opt < %s -S -passes="default" -unroll-runtime=true -unroll-threshold-default=0 -unroll-threshold-aggressive=300 | FileCheck %s -check-prefix=Oz
+
+; Check that Os and Oz are optimized like O2, not like O3. To easily highlight
+; the behavior, we artificially disable unrolling for anything but O3 by setting
+; the default threshold to 0.
+
+; O3: loop2.preheader
+; O2-NOT: loop2.preheader
+; Os-NOT: loop2.preheader
+; Oz-NOT: loop2.preheader
+
+define void @unroll(i32 %iter, i32* %addr1, i32* %addr2) nounwind {
+entry:
+  br label %loop1
+
+loop1:
+  %iv1 = phi i32 [ 0, %entry ], [ %inc1, %loop1.latch ]
+  %offset1 = getelementptr i32, i32* %addr1, i32 %iv1
+  store i32 %iv1, i32* %offset1, align 4
+  br label %loop2.header
+
+loop2.header:
+  %e = icmp uge i32 %iter, 1
+  br i1 %e, label %loop2, label %exit2
+
+loop2:
+  %iv2 = phi i32 [ 0, %loop2.header ], [ %inc2, %loop2 ]
+  %offset2 = getelementptr i32, i32* %addr2, i32 %iv2
+  store i32 %iv2, i32* %offset2, align 4
+  %inc2 = add i32 %iv2, 1
+  %exitcnd2 = icmp uge i32 %inc2, %iter
+  br i1 %exitcnd2, label 

[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

2020-01-15 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGb72a8c65e4e3: PR17164: Change clangs default behavior 
from -flax-vector-conversions=all to… (authored by Richard Smith 
richard-l...@metafoo.co.uk, committed by rsmith).

Changed prior to commit:
  https://reviews.llvm.org/D67678?vs=238099=238351#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67678

Files:
  clang/docs/CommandGuide/clang.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/LangOptions.def
  clang/test/Headers/altivec-header.c
  clang/test/Headers/arm-neon-header.c
  clang/test/Headers/x86-intrinsics-headers.c
  clang/test/Headers/x86intrin-2.c
  clang/test/Headers/x86intrin.c
  clang/test/Sema/vector-assign.c
  clang/test/Sema/vector-cast.c
  clang/test/Sema/vector-ops.c

Index: clang/test/Sema/vector-ops.c
===
--- clang/test/Sema/vector-ops.c
+++ clang/test/Sema/vector-ops.c
@@ -1,4 +1,5 @@
-// RUN: %clang_cc1 %s -verify -fsyntax-only -Wvector-conversion -triple x86_64-apple-darwin10
+// RUN: %clang_cc1 %s -verify -fsyntax-only -Wvector-conversion -triple x86_64-apple-darwin10 -flax-vector-conversions=all
+// FIXME: We get worse diagnostics here with -flax-vector-conversions disabled.
 typedef unsigned int v2u __attribute__ ((vector_size (8)));
 typedef int v2s __attribute__ ((vector_size (8)));
 typedef float v2f __attribute__ ((vector_size(8)));
Index: clang/test/Sema/vector-cast.c
===
--- clang/test/Sema/vector-cast.c
+++ clang/test/Sema/vector-cast.c
@@ -1,4 +1,5 @@
-// RUN: %clang_cc1 -fsyntax-only %s -verify -Wvector-conversion
+// RUN: %clang_cc1 -fsyntax-only %s -verify=expected,no-lax -Wvector-conversion -flax-vector-conversions=none
+// RUN: %clang_cc1 -fsyntax-only %s -verify=expected,lax -Wvector-conversion -flax-vector-conversions=all
 
 typedef long long t1 __attribute__ ((vector_size (8)));
 typedef char t2 __attribute__ ((vector_size (16)));
@@ -41,7 +42,9 @@
 void f2(t2 X); // expected-note{{passing argument to parameter 'X' here}}
 
 void f3(t3 Y) {
-  f2(Y);  // expected-warning {{incompatible vector types passing 't3' (vector of 4 'float' values) to parameter of type 't2' (vector of 16 'char' values)}}
+  f2(Y);
+  // lax-warning@-1 {{incompatible vector types passing 't3' (vector of 4 'float' values) to parameter of type 't2' (vector of 16 'char' values)}}
+  // no-lax-error@-2 {{passing 't3' (vector of 4 'float' values) to parameter of incompatible type 't2' (vector of 16 'char' values)}}
 }
 
 typedef float float2 __attribute__ ((vector_size (8)));
@@ -58,13 +61,15 @@
   float64x2_t v = {0.0, 1.0};
   f2 += d; // expected-error {{cannot convert between scalar type 'double' and vector type 'float2' (vector of 2 'float' values) as implicit conversion would cause truncation}}
   d += f2; // expected-error {{assigning to 'double' from incompatible type 'float2' (vector of 2 'float' values)}}
-  a = 3.0 + vget_low_f64(v);
-  b = vget_low_f64(v) + 3.0;
-  c = vget_low_f64(v);
-  c -= vget_low_f64(v);
+  a = 3.0 + vget_low_f64(v); // no-lax-error {{assigning to 'double' from incompatible type 'float64x1_t' (vector of 1 'double' value)}}
+  b = vget_low_f64(v) + 3.0; // no-lax-error {{assigning to 'double' from incompatible type 'float64x1_t' (vector of 1 'double' value)}}
+  c = vget_low_f64(v); // no-lax-error {{assigning to 'double' from incompatible type 'float64x1_t' (vector of 1 'double' value)}}
+  c -= vget_low_f64(v); // no-lax-error {{assigning to 'double' from incompatible type 'float64x1_t' (vector of 1 'double' value)}}
   // LAX conversions between scalar and vector types require same size and one element sized vectors.
   d = f2; // expected-error {{assigning to 'double' from incompatible type 'float2'}}
-  d = d + f2; // expected-error {{assigning to 'double' from incompatible type 'float2'}}
+  d = d + f2;
+  // lax-error@-1 {{assigning to 'double' from incompatible type 'float2' (vector of 2 'float' values)}}
+  // no-lax-error@-2 {{cannot convert between scalar type 'double' and vector type 'float2' (vector of 2 'float' values) as implicit conversion would cause truncation}}
 }
 
 // rdar://15931426
@@ -78,6 +83,8 @@
 }
 
 void f6(vSInt32 a0) {
-  vUInt32 counter = (float16){0.0f, 0.0f, 0.0f, 0.0f}; // expected-warning {{incompatible vector types initializing 'vUInt32' (vector of 4 'unsigned int' values) with an expression of type 'float16' (vector of 4 'float' values)}}
+  vUInt32 counter = (float16){0.0f, 0.0f, 0.0f, 0.0f};
+  // lax-warning@-1 {{incompatible vector types initializing 'vUInt32' (vector of 4 'unsigned int' values) with an expression of type 'float16' (vector of 4 'float' values)}}
+  // no-lax-error@-2 {{initializing 'vUInt32' (vector of 4 'unsigned int' values) with an expression of incompatible type 'float16' (vector of 

Re: [clang] b72a8c6 - PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

2020-01-15 Thread Richard Smith via cfe-commits
Hi Hans,

This flag flip just missed the branch point; can it be applied to the Clang
10 branch? (You'll also need 388eaa1.) Let me know if that's OK, and I'll
remove the changes to the release notes from master. (Otherwise the version
number in which this applies needs to be bumped.)

On Wed, 15 Jan 2020 at 13:16, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
> Author: Richard Smith
> Date: 2020-01-15T13:14:57-08:00
> New Revision: b72a8c65e4e34779b6bc9e466203f553f5294486
>
> URL:
> https://github.com/llvm/llvm-project/commit/b72a8c65e4e34779b6bc9e466203f553f5294486
> DIFF:
> https://github.com/llvm/llvm-project/commit/b72a8c65e4e34779b6bc9e466203f553f5294486.diff
>
> LOG: PR17164: Change clang's default behavior from
> -flax-vector-conversions=all to -flax-vector-conversions=integer.
>
> Summary:
> See proposal on cfe-dev:
> http://lists.llvm.org/pipermail/cfe-dev/2019-April/062030.html
>
> Reviewers: SjoerdMeijer, eli.friedman
>
> Subscribers: kristof.beyls, cfe-commits
>
> Tags: #clang
>
> Differential Revision: https://reviews.llvm.org/D67678
>
> Added:
>
>
> Modified:
> clang/docs/CommandGuide/clang.rst
> clang/docs/ReleaseNotes.rst
> clang/include/clang/Basic/LangOptions.def
> clang/test/Headers/altivec-header.c
> clang/test/Headers/arm-neon-header.c
> clang/test/Headers/x86-intrinsics-headers.c
> clang/test/Headers/x86intrin-2.c
> clang/test/Headers/x86intrin.c
> clang/test/Sema/vector-assign.c
> clang/test/Sema/vector-cast.c
> clang/test/Sema/vector-ops.c
>
> Removed:
>
>
>
>
> 
> diff  --git a/clang/docs/CommandGuide/clang.rst
> b/clang/docs/CommandGuide/clang.rst
> index 7b0873600fc3..6947450beb43 100644
> --- a/clang/docs/CommandGuide/clang.rst
> +++ b/clang/docs/CommandGuide/clang.rst
> @@ -278,9 +278,18 @@ Language Selection and Mode Options
>   Make all string literals default to writable.  This disables uniquing of
>   strings and other optimizations.
>
> -.. option:: -flax-vector-conversions
> +.. option:: -flax-vector-conversions, -flax-vector-conversions=,
> -fno-lax-vector-conversions
>
>   Allow loose type checking rules for implicit vector conversions.
> + Possible values of :
> +
> + - ``none``: allow no implicit conversions between vectors
> + - ``integer``: allow implicit bitcasts between integer vectors of the
> same
> +   overall bit-width
> + - ``all``: allow implicit bitcasts between any vectors of the same
> +   overall bit-width
> +
> +  defaults to ``integer`` if unspecified.
>
>  .. option:: -fblocks
>
>
> diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
> index e5b5438216ef..d081c885a0b3 100644
> --- a/clang/docs/ReleaseNotes.rst
> +++ b/clang/docs/ReleaseNotes.rst
> @@ -62,6 +62,15 @@ Non-comprehensive list of changes in this release
>  -
>
>
> +* Lax vector conversions involving floating-point vectors have been
> disabled
> +  by default, and can no longer be enabled with
> ``-flax-vector-conversions``.
> +  This matches the behavior of these flags in GCC, but code relying on
> implicit
> +  vector bitcasts between integer and floating-point types that used to
> compile
> +  with older versions of Clang is no longer accepted by default in Clang
> 10.
> +  The old behavior can be restored with ``-flax-vector-conversions=all``.
> +  In a future release of Clang, we intend to change the default to
> +  ``-fno-lax-vector-conversions``.
> +
>  New Compiler Flags
>  --
>
> @@ -78,6 +87,21 @@ Modified Compiler Flags
>  ---
>
>
> +- ``-flax-vector-conversions`` has been split into three
> diff erent levels of
> +  laxness:
> +
> +  - ``-flax-vector-conversions=all``: This is Clang's historical default,
> and
> +permits implicit vector conversions (performed as bitcasts) between
> any
> +two vector types of the same overall bit-width.
> +
> +  - ``-flax-vector-conversions=integer``: This is Clang's current default,
> +and permits implicit vector conversions (performed as bitcasts)
> between
> +any two integer vector types of the same overall bit-width.
> +Synonym: ``-flax-vector-conversions``.
> +
> +  - ``-flax-vector-conversions=none``: Do not perform any implicit
> bitcasts
> +between vector types. Synonym: ``-fno-lax-vector-conversions``.
> +
>  New Pragmas in Clang
>  
>
>
> diff  --git a/clang/include/clang/Basic/LangOptions.def
> b/clang/include/clang/Basic/LangOptions.def
> index 068f206f4484..4bbe6ea26fba 100644
> --- a/clang/include/clang/Basic/LangOptions.def
> +++ b/clang/include/clang/Basic/LangOptions.def
> @@ -121,7 +121,7 @@ BENIGN_LANGOPT(PascalStrings, 1, 0, "Pascal string
> support")
>  LANGOPT(WritableStrings   , 1, 0, "writable string support")
>  LANGOPT(ConstStrings  , 1, 0, "const-qualified string support")
>  ENUM_LANGOPT(LaxVectorConversions, 

[PATCH] D72742: Don't assume promotable integers are zero/sign-extended already in x86-64 ABI.

2020-01-15 Thread Emilio Cobos Álvarez via Phabricator via cfe-commits
emilio added a comment.

In D72742#1822554 , @rnk wrote:

> +@chandlerc @rjmccall
>
> Didn't we work this out already when John added the alignment tracking stuff? 
> I remember this bug involving libjpegturbo standalone assembly receiving a 
> 32-bit argument, and then using the full 64-bit RDI register to read it, but 
> clang stopped zero extending it. I thought the ABI doc was ambiguous at the 
> time, and we studied GCC's behavior, and that is how we arrived at clang's 
> current behavior. I am generally skeptical about changing behavior in this 
> area just because the ABI doc says something now. It keeps changing. What did 
> it say in the past? Shouldn't we pay more attention to that?
>
> Found the libjpegturbo thing:
>  
> https://github.com/libjpeg-turbo/libjpeg-turbo/commit/498d9bc92fcf39124b6f08e57326944dedd2ddd6


That seems somewhat related. This would be a similar change to the one that 
clang did back then, but for the bytes in the lower 32-bits when the argument 
is smaller than that.

The ABI document, afaict, has never defined the inputs to be zero-extended. See 
https://groups.google.com/forum/?hl=en#!topic/x86-64-abi/E8O33onbnGQ for an old 
thread discussing this, and the two bugs that are referenced in the commit 
message (one of them fairly old).

GCC does avoid the zero-extension on the caller sometimes, when not required by 
the language and when its optimizer finds it suitable.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72742



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


[clang] b72a8c6 - PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

2020-01-15 Thread Richard Smith via cfe-commits

Author: Richard Smith
Date: 2020-01-15T13:14:57-08:00
New Revision: b72a8c65e4e34779b6bc9e466203f553f5294486

URL: 
https://github.com/llvm/llvm-project/commit/b72a8c65e4e34779b6bc9e466203f553f5294486
DIFF: 
https://github.com/llvm/llvm-project/commit/b72a8c65e4e34779b6bc9e466203f553f5294486.diff

LOG: PR17164: Change clang's default behavior from -flax-vector-conversions=all 
to -flax-vector-conversions=integer.

Summary:
See proposal on cfe-dev:
http://lists.llvm.org/pipermail/cfe-dev/2019-April/062030.html

Reviewers: SjoerdMeijer, eli.friedman

Subscribers: kristof.beyls, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D67678

Added: 


Modified: 
clang/docs/CommandGuide/clang.rst
clang/docs/ReleaseNotes.rst
clang/include/clang/Basic/LangOptions.def
clang/test/Headers/altivec-header.c
clang/test/Headers/arm-neon-header.c
clang/test/Headers/x86-intrinsics-headers.c
clang/test/Headers/x86intrin-2.c
clang/test/Headers/x86intrin.c
clang/test/Sema/vector-assign.c
clang/test/Sema/vector-cast.c
clang/test/Sema/vector-ops.c

Removed: 




diff  --git a/clang/docs/CommandGuide/clang.rst 
b/clang/docs/CommandGuide/clang.rst
index 7b0873600fc3..6947450beb43 100644
--- a/clang/docs/CommandGuide/clang.rst
+++ b/clang/docs/CommandGuide/clang.rst
@@ -278,9 +278,18 @@ Language Selection and Mode Options
  Make all string literals default to writable.  This disables uniquing of
  strings and other optimizations.
 
-.. option:: -flax-vector-conversions
+.. option:: -flax-vector-conversions, -flax-vector-conversions=, 
-fno-lax-vector-conversions
 
  Allow loose type checking rules for implicit vector conversions.
+ Possible values of :
+
+ - ``none``: allow no implicit conversions between vectors
+ - ``integer``: allow implicit bitcasts between integer vectors of the same
+   overall bit-width
+ - ``all``: allow implicit bitcasts between any vectors of the same
+   overall bit-width
+
+  defaults to ``integer`` if unspecified.
 
 .. option:: -fblocks
 

diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index e5b5438216ef..d081c885a0b3 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -62,6 +62,15 @@ Non-comprehensive list of changes in this release
 -
 
 
+* Lax vector conversions involving floating-point vectors have been disabled
+  by default, and can no longer be enabled with ``-flax-vector-conversions``.
+  This matches the behavior of these flags in GCC, but code relying on implicit
+  vector bitcasts between integer and floating-point types that used to compile
+  with older versions of Clang is no longer accepted by default in Clang 10.
+  The old behavior can be restored with ``-flax-vector-conversions=all``.
+  In a future release of Clang, we intend to change the default to
+  ``-fno-lax-vector-conversions``.
+
 New Compiler Flags
 --
 
@@ -78,6 +87,21 @@ Modified Compiler Flags
 ---
 
 
+- ``-flax-vector-conversions`` has been split into three 
diff erent levels of
+  laxness:
+
+  - ``-flax-vector-conversions=all``: This is Clang's historical default, and
+permits implicit vector conversions (performed as bitcasts) between any
+two vector types of the same overall bit-width.
+
+  - ``-flax-vector-conversions=integer``: This is Clang's current default,
+and permits implicit vector conversions (performed as bitcasts) between
+any two integer vector types of the same overall bit-width.
+Synonym: ``-flax-vector-conversions``.
+
+  - ``-flax-vector-conversions=none``: Do not perform any implicit bitcasts
+between vector types. Synonym: ``-fno-lax-vector-conversions``.
+
 New Pragmas in Clang
 
 

diff  --git a/clang/include/clang/Basic/LangOptions.def 
b/clang/include/clang/Basic/LangOptions.def
index 068f206f4484..4bbe6ea26fba 100644
--- a/clang/include/clang/Basic/LangOptions.def
+++ b/clang/include/clang/Basic/LangOptions.def
@@ -121,7 +121,7 @@ BENIGN_LANGOPT(PascalStrings, 1, 0, "Pascal string support")
 LANGOPT(WritableStrings   , 1, 0, "writable string support")
 LANGOPT(ConstStrings  , 1, 0, "const-qualified string support")
 ENUM_LANGOPT(LaxVectorConversions, LaxVectorConversionKind, 2,
- LaxVectorConversionKind::All, "lax vector conversions")
+ LaxVectorConversionKind::Integer, "lax vector conversions")
 LANGOPT(ConvergentFunctions, 1, 1, "Assume convergent functions")
 LANGOPT(AltiVec   , 1, 0, "AltiVec-style vector initializers")
 LANGOPT(ZVector   , 1, 0, "System z vector extensions")

diff  --git a/clang/test/Headers/altivec-header.c 
b/clang/test/Headers/altivec-header.c
index 00e5f444de7c..aa85a33d26da 100644
--- a/clang/test/Headers/altivec-header.c
+++ b/clang/test/Headers/altivec-header.c
@@ -1,5 +1,5 @@
-// RUN: 

[clang] 388eaa1 - Work around PR43337: don't try to use the vec_sel overloads for vector long long, since clang's doesn't provide it yet!

2020-01-15 Thread Richard Smith via cfe-commits

Author: Richard Smith
Date: 2020-01-15T13:14:57-08:00
New Revision: 388eaa1270c2762d61b756759b6db8cf15bd3a83

URL: 
https://github.com/llvm/llvm-project/commit/388eaa1270c2762d61b756759b6db8cf15bd3a83
DIFF: 
https://github.com/llvm/llvm-project/commit/388eaa1270c2762d61b756759b6db8cf15bd3a83.diff

LOG: Work around PR43337: don't try to use the vec_sel overloads for vector 
long long, since clang's  doesn't provide it yet!

Added: 


Modified: 
clang/lib/Headers/ppc_wrappers/emmintrin.h

Removed: 




diff  --git a/clang/lib/Headers/ppc_wrappers/emmintrin.h 
b/clang/lib/Headers/ppc_wrappers/emmintrin.h
index 293276cc9be0..4dcb8485e2e9 100644
--- a/clang/lib/Headers/ppc_wrappers/emmintrin.h
+++ b/clang/lib/Headers/ppc_wrappers/emmintrin.h
@@ -1749,7 +1749,7 @@ _mm_sll_epi64 (__m128i __A, __m128i __B)
   lshift = vec_splat ((__v2du) __B, 0);
   shmask = vec_cmplt (lshift, shmax);
   result = vec_sl ((__v2du) __A, lshift);
-  result = vec_sel ((__v2du) shmask, result, shmask);
+  result = (__v2du)vec_sel ((__v2df) shmask, (__v2df)result, shmask);
 
   return (__m128i) result;
 }
@@ -1843,7 +1843,7 @@ _mm_srl_epi64 (__m128i __A, __m128i __B)
   rshift = vec_splat ((__v2du) __B, 0);
   shmask = vec_cmplt (rshift, shmax);
   result = vec_sr ((__v2du) __A, rshift);
-  result = vec_sel ((__v2du) shmask, result, shmask);
+  result = (__v2du)vec_sel ((__v2df) shmask, (__v2df)result, shmask);
 
   return (__m128i) result;
 }



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


[PATCH] D72635: Add "context" capability to Thread Safety Analysis

2020-01-15 Thread Etienne Pierre-Doray via Phabricator via cfe-commits
eti-p-doray added a comment.

I added an example in the description.

From doc https://clang.llvm.org/docs/ThreadSafetyAnalysis.html, 
it sounds like we should be allowed to declare our class with 
CAPABILITY("context"), but it turns out that only "mutex" and "role" are 
allowed.
I could otherwise update this CL to allow any string (single word lowercase?) 
as CAPABILITY?


Repository:
  rC Clang

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

https://reviews.llvm.org/D72635



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


[PATCH] D67847: [Support] make report_fatal_error `abort` instead of `exit`

2020-01-15 Thread Yuanfang Chen via Phabricator via cfe-commits
ychen added a comment.

Apologies that it takes so long. I'll fix the test and land it today.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67847



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


[PATCH] D72073: [Sema] Fix location of star ('*') inside MemberPointerTypeLoc

2020-01-15 Thread Dmitri Gribenko via Phabricator via cfe-commits
gribozavr2 added inline comments.



Comment at: clang/lib/Parse/ParseDecl.cpp:5556
+  SourceLocation StarLoc = Tok.getLocation();
   SourceLocation Loc = ConsumeToken();
   D.SetRangeEnd(Loc);

ConsumeToken() returns Tok.getLocation(), so why do we need a separate variable?

D.SetRangeEnd() sets the end of source range to Tok.getLocation, which is then 
propagated to DeclSpec... I don't think this patch changes the behavior. Is 
this change testable?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72073



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


[PATCH] D67847: [Support] make report_fatal_error `abort` instead of `exit`

2020-01-15 Thread James Y Knight via Phabricator via cfe-commits
jyknight added a comment.

In D67847#1693694 , @rnk wrote:

> In D67847#1691898 , @jyknight wrote:
>
> > The `abort()` function raises SIGABRT, for which the default behavior is to 
> > trigger a coredump. Do we actually want that behavior?
> >
> > Either `_exit()` (long available extension, which lld already uses) or 
> > `quick_exit()` (the new C standard way) seem possibly preferable?
>
>
> It's easy to crash LLVM even without this change, so anyone running LLVM 
> better have core dumps configured the way they like. Failed asserts raise 
> SIGABRT already, for example, and we have tons of those. The only difference 
> is that now end users, who may have never configured this stuff, may see more 
> crashes. If it's a problem, I'd consider it QoI: we should fix the 
> report_fatal_error to use proper diagnostics anyway so end users don't see 
> them as often, just as we would treat any other user-visible crash.


That may be, but right now we do report a bunch of errors via 
report_fatal_error, even if we should not. Coredumps seem unlikely to be of use 
in diagnosing the issue involved (unlike, perhaps, with a segfault), so I don't 
see why we'd _want_ to call abort vs quick_exit/_exit.

I express this as my opinion, but do not veto acceptance given by others.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67847



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


[PATCH] D72334: [Syntax] Build nodes for template declarations.

2020-01-15 Thread Dmitri Gribenko via Phabricator via cfe-commits
gribozavr2 added inline comments.



Comment at: clang/lib/Tooling/Syntax/BuildTree.cpp:930
+Builder.markChildToken(TemplateKW, syntax::NodeRole::IntroducerKeyword);
+Builder.markMaybeDelayedChild(
+TemplatedDeclaration,

Why is this range maybe-delayed?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72334



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


[PATCH] D72334: [Syntax] Build nodes for template declarations.

2020-01-15 Thread Dmitri Gribenko via Phabricator via cfe-commits
gribozavr2 accepted this revision.
gribozavr2 added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/lib/Tooling/Syntax/BuildTree.cpp:190
+  // Set role for the node that may or may not be delayed. Node must span
+  // exactly \p Range.
+  void markMaybeDelayedChild(llvm::ArrayRef Range, NodeRole R);

Three slashes for docs.



Comment at: clang/unittests/Tooling/Syntax/TreeTest.cpp:738
+  U foo();
+};
+)cpp",

Could you also add an out-of-line definition of X::foo? It will have two 
template parameter lists, which is a special case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72334



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


[PATCH] D67847: [Support] make report_fatal_error `abort` instead of `exit`

2020-01-15 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added a comment.

I'm still in favor of this change.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67847



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


[PATCH] D72742: Don't assume promotable integers are zero/sign-extended already in x86-64 ABI.

2020-01-15 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added subscribers: rjmccall, chandlerc.
rnk added a comment.

+@chandlerc @rjmccall

Didn't we work this out already when John added the alignment tracking stuff? I 
remember this bug involving libjpegturbo standalone assembly receiving a 32-bit 
argument, and then using the full 64-bit RDI register to read it, but clang 
stopped zero extending it. I thought the ABI doc was ambiguous at the time, and 
we studied GCC's behavior, and that is how we arrived at clang's current 
behavior. I am generally skeptical about changing behavior in this area just 
because the ABI doc says something now. It keeps changing. What did it say in 
the past? Shouldn't we pay more attention to that?

Found the libjpegturbo thing:
https://github.com/libjpeg-turbo/libjpeg-turbo/commit/498d9bc92fcf39124b6f08e57326944dedd2ddd6


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72742



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


[PATCH] D67847: [Support] make report_fatal_error `abort` instead of `exit`

2020-01-15 Thread pre-merge checks [bot] via Phabricator via cfe-commits
merge_guards_bot added a comment.

{icon times-circle color=red} Unit tests: fail. 61892 tests passed, 2 failed 
and 782 were skipped.

  failed: Clang.CXX/temp/temp_arg/temp_arg_template/p3-2a.cpp
  failed: LLVM.CodeGen/SystemZ/mverify-optypes.mir

{icon question-circle color=gray} clang-tidy: unknown.

{icon times-circle color=red} clang-format: fail. Please format your changes 
with clang-format by running `git-clang-format HEAD^` or applying this patch 
.

Build artifacts 
: 
diff.json 
,
 clang-format.patch 
,
 CMakeCache.txt 
,
 console-log.txt 
,
 test-results.xml 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67847



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


[PATCH] D71451: Support to emit extern variables debuginfo with "-fstandalone-debug"

2020-01-15 Thread David Blaikie via Phabricator via cfe-commits
dblaikie added a comment.

In D71451#1822497 , @Jac1494 wrote:

> >> I'd be curious to the answer to David's questions. If the size increase is 
> >> because of unused extern variables coming in from libc or something then 
> >> it doesn't seem worth the cost.
>
> For above case clang size is increase because ,it is difference between clang 
> build without "-fstandalone-debug" option and clang build with 
> "-fstandalone-debug"  option and both build contain change D71451 
>  and D71599 
>  . So for clang build with 
> "-fstandalone-debug"  option size will be more because it will add debuginfo.
>
> And to check impact of my change on clang i have build clang with and without 
> D71451  and D71599 
>  change(testcases are not included).
>
> Size of clang without D71451  and D71599 
>  change and with option 
> "-fstandalone-debug":-
>  ===
> …
>  .comment 159 0
>  .debug_str   3994952 0
>  .debug_loc   941 0
>  .debug_abbrev  12754 0
>  .debug_info  2223641 0
>  .debug_ranges  46592 0
>  .debug_line   153901 0
>  .note.gnu.gold-version28 0
>  Total6827932
>
> Size of clang with D71451  and D71599 
>  change and with option  
> "-fstandalone-debug":-
>  ==
> …
>  .comment 159 0
>  .debug_str   3994894 0
>  .debug_loc   941 0
>  .debug_abbrev  12746 0
>  .debug_info  2223617 0
>  .debug_ranges  46592 0
>  .debug_line   153865 0
>  .note.gnu.gold-version28 0
>  Total6827806
>
> Size of clang with D71451  and D71599 
>  is reduced.


Do you have any reason to believe these patches would reduce the size of the 
debug info? It seems like they only add more debug info, and don't remove 
anything - so we'd expect an increase in the size, certainly not a decrease. 
That means, to me, there's probably a mistake in the measurement somehow?

> This results are with latest source and with self-host build of clang. First 
> I have build clang with Release mode and using that clang I have build clang 
> with debug mode with below options
> 
> “cmake -DLLVM_ENABLE_PROJECTS=clang -DCMAKE_BUILD_TYPE=Debug 
> -DCMAKE_C_COMPILER=$(which clang) -DCMAKE_CXX_COMPILER=$(which clang++) 
> -DLLVM_TARGETS_TO_BUILD="X86" -DBUILD_SHARED_LIBS=On  
> -DCMAKE_CXX_FLAGS="-fstandalone-debug"   -DCMAKE_C_FLAGS="-fstandalone-debug" 
>  
> -DCMAKE_INSTALL_PREFIX=/home/bft/Jaydeep/latest_llvm/llvm-project/install_withhstandalone
>  ../llvm”




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

https://reviews.llvm.org/D71451



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


[PATCH] D72282: [clang-tidy] Add `bugprone-unintended-adl`

2020-01-15 Thread Logan Smith via Phabricator via cfe-commits
logan-5 updated this revision to Diff 238328.
logan-5 added a comment.

Added TODO comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72282

Files:
  clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
  clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
  clang-tools-extra/clang-tidy/bugprone/UnintendedADLCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/UnintendedADLCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/bugprone-unintended-adl.rst
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-unintended-adl-generic-lambdas.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-unintended-adl-operators.cpp
  clang-tools-extra/test/clang-tidy/checkers/bugprone-unintended-adl.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-unintended-adl.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-unintended-adl.cpp
@@ -0,0 +1,162 @@
+// RUN: %check_clang_tidy %s bugprone-unintended-adl %t
+
+namespace aspace {
+struct A {};
+void func(const A &);
+} // namespace aspace
+
+namespace bspace {
+void func(int);
+void test() {
+  aspace::A a;
+  func(5);
+  func(a);
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: expression calls 'aspace::func' through ADL [bugprone-unintended-adl]
+}
+} // namespace bspace
+
+namespace ops {
+
+struct Stream {
+} stream;
+Stream <<(Stream , int) {
+  return s;
+}
+Stream <<(Stream , aspace::A) {
+  return s;
+}
+template 
+IStream >>(IStream , int) {
+  return s;
+}
+template 
+IStream >>(IStream , aspace::A) {
+  return s;
+}
+void smooth_operator(Stream);
+
+} // namespace ops
+
+void ops_test() {
+  ops::stream << 5;
+  // no warning
+  operator<<(ops::stream, 5);
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: expression calls 'ops::operator<<' through ADL [bugprone-unintended-adl]
+  ops::stream << aspace::A();
+  // no warning
+  operator<<(ops::stream, aspace::A());
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: expression calls 'ops::operator<<' through ADL [bugprone-unintended-adl]
+
+  ops::stream >> aspace::A();
+  // no warning
+  operator>>(ops::stream, aspace::A());
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: expression calls 'ops::operator>>' through ADL [bugprone-unintended-adl]
+
+  smooth_operator(ops::stream);
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: expression calls 'ops::smooth_operator' through ADL [bugprone-unintended-adl]
+}
+
+namespace std {
+// return types don't matter, returning 'void' everywhere for simplicity
+
+template 
+void swap(T , T );
+template 
+void make_error_code(T);
+template 
+void make_error_condition(T);
+
+template 
+void move(T &&);
+template 
+void forward(T &&);
+
+struct byte {};
+
+} // namespace std
+namespace ns {
+
+struct Swappable {};
+
+// whitelisted
+void swap(Swappable , Swappable );
+void make_error_code(Swappable);
+void make_error_condition(Swappable);
+
+// non-whitelisted
+void move(Swappable);
+void ref(Swappable);
+
+struct Swappable2 {};
+
+} // namespace ns
+struct {
+  template 
+  void operator()(T &&);
+} ref;
+
+void test2() {
+  // TODO add granularity for detecting functions that may always be called unqualified,
+  // versus those that can only be called through the 'using' 'two-step'
+  using namespace std;
+  ns::Swappable a, b;
+  swap(a, b);
+  make_error_code(a);
+  make_error_condition(a);
+  move(a);
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: expression calls 'ns::move' through ADL [bugprone-unintended-adl]
+}
+
+template 
+void foo(T t) {
+  using namespace std;
+  swap(t, t);
+  make_error_code(t);
+  make_error_condition(t);
+
+  move(t);
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: expression calls 'ns::move' through ADL [bugprone-unintended-adl]
+  // CHECK-MESSAGES: [[@LINE-2]]:3: note: with argument type 'struct ns::Swappable'
+  // CHECK-MESSAGES: [[@LINE-3]]:3: warning: unqualified call to 'move' may be resolved through ADL [bugprone-unintended-adl]
+
+  std::swap(t, t);
+  std::move(t);
+
+  ref(t); // function objects bypass ADL, this always calls ::ref
+  ::ref(t);
+}
+
+template 
+void operator<<(T &&, U &&);
+
+template 
+void bar(T t) {
+  t << 5;
+  operator<<(t, 5);
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: expression calls 'ops::operator<<' through ADL [bugprone-unintended-adl]
+  // CHECK-MESSAGES: [[@LINE-2]]:3: note: with argument types 'struct ops::Stream', 'int'
+  // CHECK-MESSAGES: [[@LINE-3]]:3: warning: unqualified call to 'operator<<' may be resolved through ADL [bugprone-unintended-adl]
+}
+
+void instantiator() {
+  foo(ns::Swappable()); // instantiation will use ADL
+  foo(5);   // instantiation will not use ADL
+
+  bar(ops::Stream()); // instantiation will use ADL
+  bar(aspace::A());   // instantiation will not use ADL
+}
+
+template 
+void macro_test(T t) {
+#define MACRO(x) find_if(x, x, x)

[PATCH] D72675: Fix -ffast-math/-ffp-contract interaction

2020-01-15 Thread Sanjay Patel via Phabricator via cfe-commits
spatel added inline comments.



Comment at: llvm/test/CodeGen/PowerPC/fmf-propagation.ll:201-203
 ; fma(X, 7.0, X * 42.0) --> X * 49.0
-; This is the minimum FMF needed for this transform - the FMA allows 
reassociation.
+; This is the minimum FMF needed for this transform - the 'contract' allows 
the needed reassociation.
+

I was ok with the reasoning up to here, but this example lost me.
Why does 'contract' alone allow splitting an fma?
Is 'contract' relevant on anything besides fadd (with an fmul operand)?


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

https://reviews.llvm.org/D72675



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


[PATCH] D72284: [clang-tidy] Factor out renaming logic from readability-identifier-naming

2020-01-15 Thread Logan Smith via Phabricator via cfe-commits
logan-5 marked 2 inline comments as done.
logan-5 added inline comments.



Comment at: clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.h:29
+public:
+  RenamerClangTidyCheck(StringRef CheckName, ClangTidyContext *Context);
+  ~RenamerClangTidyCheck();

logan-5 wrote:
> njames93 wrote:
> > Should this be protected as this class should never be instantiated 
> > directly. Also the definition could be moved inline as its just a 
> > delegating constructor
> The constructor (and destructor) can't be inline, since they need to be able 
> to see the specialization of `DenseMapInfo` in the cpp.
> 
> I could change it to `protected` to clean up the interface -- though it won't 
> strictly change anything, since the class already has pure virtual functions 
> so it's not instantiable.
Searched the LLVM codebase for other abstract base classes with explicitly 
defined constructors (e.g. `MakeSmartPtrCheck` in clang-tidy), and their 
constructors seem to be public. I think I'll keep this one public too for 
consistency.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72284



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


[PATCH] D71451: Support to emit extern variables debuginfo with "-fstandalone-debug"

2020-01-15 Thread Jaydeep Chauhan via Phabricator via cfe-commits
Jac1494 added a comment.

>> I'd be curious to the answer to David's questions. If the size increase is 
>> because of unused extern variables coming in from libc or something then it 
>> doesn't seem worth the cost.

For above case clang size is increase because ,it is difference between clang 
build without "-fstandalone-debug" option and clang build with 
"-fstandalone-debug"  option and both build contain change D71451 
 and D71599  
. So for clang build with "-fstandalone-debug"  option size will be more 
because it will add debuginfo.

And to check impact of my change on clang i have build clang with and without 
D71451  and D71599 
 change(testcases are not included).

Size of clang without D71451 and D71599 change and with option 
"-fstandalone-debug":-
=

…
.comment 159 0
.debug_str   3994952 0
.debug_loc   941 0
.debug_abbrev  12754 0
.debug_info  2223641 0
.debug_ranges  46592 0
.debug_line   153901 0
.note.gnu.gold-version28 0
Total6827932

Size of clang with D71451 and D71599 change and with option  
"-fstandalone-debug":-
===

…
.comment 159 0
.debug_str   3994894 0
.debug_loc   941 0
.debug_abbrev  12746 0
.debug_info  2223617 0
.debug_ranges  46592 0
.debug_line   153865 0
.note.gnu.gold-version28 0
Total6827806

Size of clang with D71451  and D71599 
 is reduced.

This results are with latest source and with self-host build of clang. First I 
have build clang with Release mode and using that clang I have build clang with 
debug mode with below options

“cmake -DLLVM_ENABLE_PROJECTS=clang -DCMAKE_BUILD_TYPE=Debug 
-DCMAKE_C_COMPILER=$(which clang) -DCMAKE_CXX_COMPILER=$(which clang++) 
-DLLVM_TARGETS_TO_BUILD="X86" -DBUILD_SHARED_LIBS=On  
-DCMAKE_CXX_FLAGS="-fstandalone-debug"   -DCMAKE_C_FLAGS="-fstandalone-debug"  
-DCMAKE_INSTALL_PREFIX=/home/bft/Jaydeep/latest_llvm/llvm-project/install_withhstandalone
 ../llvm”


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

https://reviews.llvm.org/D71451



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


[PATCH] D72786: [clang] Set function attributes on SEH filter functions correctly.

2020-01-15 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added a comment.

Thanks, the code change looks good, but please adjust the tests a bit.




Comment at: clang/test/CodeGen/exceptions-seh-finally.c:284-286
-// Look for the absence of noinline. Enum attributes come first, so check that
-// a string attribute is the first to verify that no enum attributes are
-// present.

We shouldn't be marking this thing noinline. I believe it appears because clang 
applies noinline everywhere at O0. Please add `-O1 -disable-llvm-passes` to the 
RUN line so that it doesn't appear. The appearance of `nounwind` should be 
expected, so keep that here.



Comment at: clang/test/CodeGenCXX/exceptions-seh-filter-uwtable.cpp:1
+// RUN: %clang_cc1 "-triple" "arm64-windowsj" "-munwind-tables" 
"-fms-compatibility" -emit-llvm %s -o - | FileCheck %s
+

Is "arm64-windowsj" a typo? Also, please add `-O1 -disable-llvm-passes` as 
above.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72786



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


[PATCH] D72793: [clang-format] Expand the SpacesAroundConditions option to include catch statements

2020-01-15 Thread Tim Wojtulewicz via Phabricator via cfe-commits
timwoj created this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This diff expands the SpacesAroundConditions option added in D68346 
 to include adding spaces to catch statements.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D72793

Files:
  clang/lib/Format/TokenAnnotator.cpp
  clang/unittests/Format/FormatTest.cpp


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -14927,6 +14927,7 @@
   verifyFormat("while ( a )\n  return;", Spaces);
   verifyFormat("while ( (a && b) )\n  return;", Spaces);
   verifyFormat("do {\n} while ( 1 != 0 );", Spaces);
+  verifyFormat("try {\n} catch ( const std::exception & ) {\n}", Spaces);
   // Check that space on the left of "::" is inserted as expected at beginning
   // of condition.
   verifyFormat("while ( ::func() )\n  return;", Spaces);
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -2596,7 +2596,7 @@
 /// otherwise.
 static bool isKeywordWithCondition(const FormatToken ) {
   return Tok.isOneOf(tok::kw_if, tok::kw_for, tok::kw_while, tok::kw_switch,
- tok::kw_constexpr);
+ tok::kw_constexpr, tok::kw_catch);
 }
 
 bool TokenAnnotator::spaceRequiredBetween(const AnnotatedLine ,


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -14927,6 +14927,7 @@
   verifyFormat("while ( a )\n  return;", Spaces);
   verifyFormat("while ( (a && b) )\n  return;", Spaces);
   verifyFormat("do {\n} while ( 1 != 0 );", Spaces);
+  verifyFormat("try {\n} catch ( const std::exception & ) {\n}", Spaces);
   // Check that space on the left of "::" is inserted as expected at beginning
   // of condition.
   verifyFormat("while ( ::func() )\n  return;", Spaces);
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -2596,7 +2596,7 @@
 /// otherwise.
 static bool isKeywordWithCondition(const FormatToken ) {
   return Tok.isOneOf(tok::kw_if, tok::kw_for, tok::kw_while, tok::kw_switch,
- tok::kw_constexpr);
+ tok::kw_constexpr, tok::kw_catch);
 }
 
 bool TokenAnnotator::spaceRequiredBetween(const AnnotatedLine ,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D69878: Consoldiate internal denormal flushing controls

2020-01-15 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm added a comment.
Herald added a subscriber: kerbowa.

ping


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

https://reviews.llvm.org/D69878



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


[PATCH] D71199: [clang-tidy] New check cppcoreguidelines-prefer-initialization-list

2020-01-15 Thread Eugene Zelenko via Phabricator via cfe-commits
Eugene.Zelenko added a comment.

By the word, please rebase, because Release Notes were reset after version 10 
branching.


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

https://reviews.llvm.org/D71199



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


[PATCH] D72761: [ARM][MVE][Intrinsics] Add VMINAQ, VMINNMAQ, VMAXAQ, VMAXNMAQ intrinsics.

2020-01-15 Thread Dave Green via Phabricator via cfe-commits
dmgreen added a comment.

Nice one. Good to see codegen changes coming out of these intrinsics.

It took a while for me to figure out what the integer instruction was doing. 
That's a strange one.

The fp case I have a question about below.




Comment at: llvm/lib/Target/ARM/ARMInstrMVE.td:3658
+// Unpredicated v(max|min)nma
+def : Pat<(VTI.Vec (unpred_op (VTI.Vec MQPR:$Qd), (fabs (VTI.Vec 
MQPR:$Qm,
+  (VTI.Vec (Inst (VTI.Vec MQPR:$Qd), (VTI.Vec MQPR:$Qm)))>;

If I'm reading the ARMARM correctly, the fp case seems to preform the abs on 
both operands.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72761



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


[PATCH] D72785: [Matrix] Add __builtin_matrix_scalar_multiply to Clang (WIP).

2020-01-15 Thread pre-merge checks [bot] via Phabricator via cfe-commits
merge_guards_bot added a comment.

{icon question-circle color=gray} Unit tests: unknown.

{icon question-circle color=gray} clang-tidy: unknown.

{icon question-circle color=gray} clang-format: unknown.

Build artifacts 
: 
diff.json 
,
 console-log.txt 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72785



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


[PATCH] D72786: [clang] Set function attributes on SEH filter functions correctly.

2020-01-15 Thread Sanne Wouda via Phabricator via cfe-commits
sanwou01 created this revision.
sanwou01 added a reviewer: rnk.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

When compiling with -munwind-tables, the SEH filter funclet needs the uwtable
function attribute, which gets automatically added if we use
SetInternalFunctionAttributes.  The filter funclet is internal so this seems
appropriate.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D72786

Files:
  clang/lib/CodeGen/CGException.cpp
  clang/test/CodeGen/exceptions-seh-finally.c
  clang/test/CodeGenCXX/exceptions-seh-filter-uwtable.cpp


Index: clang/test/CodeGenCXX/exceptions-seh-filter-uwtable.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/exceptions-seh-filter-uwtable.cpp
@@ -0,0 +1,46 @@
+// RUN: %clang_cc1 "-triple" "arm64-windowsj" "-munwind-tables" 
"-fms-compatibility" -emit-llvm %s -o - | FileCheck %s
+
+# 0 "" 3
+#define a(b, c) d() & b
+#define f(c) a(e(0, 0, #c).b(), )
+
+struct e {
+  e(int, int, char *);
+  int b();
+};
+
+struct d {
+  void operator&(int);
+};
+
+struct h;
+
+struct i {
+  h *operator->();
+  h *() { f(); }
+};
+
+typedef int g;
+
+struct h {
+  void ad();
+};
+
+g aq(h j, g k, int, int) {
+  if (k)
+return;
+  j.ad();
+}
+
+// CHECK: define internal i32 @"?filt$0@0@at@@"(i8* %exception_pointers, i8* 
%frame_pointer) #[[MD:[0-9]+]]
+// CHECK: attributes #[[MD]] = { noinline nounwind uwtable 
+
+void at() {
+  i ar;
+
+  __try {
+ar->ad();
+  } __except (aq(*ar, _exception_code(), 0, 0)) {
+  }
+
+}
Index: clang/test/CodeGen/exceptions-seh-finally.c
===
--- clang/test/CodeGen/exceptions-seh-finally.c
+++ clang/test/CodeGen/exceptions-seh-finally.c
@@ -281,7 +281,5 @@
 // CHECK-LABEL: define internal void @"?fin$0@0@finally_with_func@@"({{[^)]*}})
 // CHECK: call void @cleanup_with_func(i8* getelementptr inbounds ([18 x i8], 
[18 x i8]* @"??_C@_0BC@COAGBPGM@finally_with_func?$AA@", i{{32|64}} 0, 
i{{32|64}} 0))
 
-// Look for the absence of noinline. Enum attributes come first, so check that
-// a string attribute is the first to verify that no enum attributes are
-// present.
-// CHECK: attributes [[finally_attrs]] = { "{{.*}}" }
+// noinline and nounwind are now added anyway
+// CHECK: attributes [[finally_attrs]] = { noinline nounwind "{{.*}}" }
Index: clang/lib/CodeGen/CGException.cpp
===
--- clang/lib/CodeGen/CGException.cpp
+++ clang/lib/CodeGen/CGException.cpp
@@ -1885,7 +1885,7 @@
 OutlinedStmt->getBeginLoc(), OutlinedStmt->getBeginLoc());
   CurSEHParent = ParentCGF.CurSEHParent;
 
-  CGM.SetLLVMFunctionAttributes(GlobalDecl(), FnInfo, CurFn);
+  CGM.SetInternalFunctionAttributes(GlobalDecl(), CurFn, FnInfo);
   EmitCapturedLocals(ParentCGF, OutlinedStmt, IsFilter);
 }
 


Index: clang/test/CodeGenCXX/exceptions-seh-filter-uwtable.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/exceptions-seh-filter-uwtable.cpp
@@ -0,0 +1,46 @@
+// RUN: %clang_cc1 "-triple" "arm64-windowsj" "-munwind-tables" "-fms-compatibility" -emit-llvm %s -o - | FileCheck %s
+
+# 0 "" 3
+#define a(b, c) d() & b
+#define f(c) a(e(0, 0, #c).b(), )
+
+struct e {
+  e(int, int, char *);
+  int b();
+};
+
+struct d {
+  void operator&(int);
+};
+
+struct h;
+
+struct i {
+  h *operator->();
+  h *() { f(); }
+};
+
+typedef int g;
+
+struct h {
+  void ad();
+};
+
+g aq(h j, g k, int, int) {
+  if (k)
+return;
+  j.ad();
+}
+
+// CHECK: define internal i32 @"?filt$0@0@at@@"(i8* %exception_pointers, i8* %frame_pointer) #[[MD:[0-9]+]]
+// CHECK: attributes #[[MD]] = { noinline nounwind uwtable 
+
+void at() {
+  i ar;
+
+  __try {
+ar->ad();
+  } __except (aq(*ar, _exception_code(), 0, 0)) {
+  }
+
+}
Index: clang/test/CodeGen/exceptions-seh-finally.c
===
--- clang/test/CodeGen/exceptions-seh-finally.c
+++ clang/test/CodeGen/exceptions-seh-finally.c
@@ -281,7 +281,5 @@
 // CHECK-LABEL: define internal void @"?fin$0@0@finally_with_func@@"({{[^)]*}})
 // CHECK: call void @cleanup_with_func(i8* getelementptr inbounds ([18 x i8], [18 x i8]* @"??_C@_0BC@COAGBPGM@finally_with_func?$AA@", i{{32|64}} 0, i{{32|64}} 0))
 
-// Look for the absence of noinline. Enum attributes come first, so check that
-// a string attribute is the first to verify that no enum attributes are
-// present.
-// CHECK: attributes [[finally_attrs]] = { "{{.*}}" }
+// noinline and nounwind are now added anyway
+// CHECK: attributes [[finally_attrs]] = { noinline nounwind "{{.*}}" }
Index: clang/lib/CodeGen/CGException.cpp
===
--- clang/lib/CodeGen/CGException.cpp
+++ clang/lib/CodeGen/CGException.cpp
@@ -1885,7 +1885,7 @@
 OutlinedStmt->getBeginLoc(), 

[PATCH] D72785: [Matrix] Add __builtin_matrix_scalar_multiply to Clang (WIP).

2020-01-15 Thread Florian Hahn via Phabricator via cfe-commits
fhahn created this revision.
Herald added a subscriber: tschuett.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D72785

Files:
  clang/include/clang/Basic/Builtins.def
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Sema/SemaChecking.cpp

Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -1619,6 +1619,7 @@
   case Builtin::BI__builtin_matrix_subtract:
   case Builtin::BI__builtin_matrix_multiply:
   case Builtin::BI__builtin_matrix_transpose:
+  case Builtin::BI__builtin_matrix_scalar_multiply:
   case Builtin::BI__builtin_matrix_column_load:
   case Builtin::BI__builtin_matrix_column_store:
 if (!getLangOpts().EnableMatrix) {
@@ -1638,6 +1639,8 @@
   return SemaBuiltinMatrixMultiplyOverload(TheCall, TheCallResult);
 case Builtin::BI__builtin_matrix_transpose:
   return SemaBuiltinMatrixTransposeOverload(TheCall, TheCallResult);
+case Builtin::BI__builtin_matrix_scalar_multiply:
+  return SemaBuiltinMatrixScalarOverload(TheCall, TheCallResult);
 case Builtin::BI__builtin_matrix_column_load:
   return SemaBuiltinMatrixColumnLoadOverload(TheCall, TheCallResult);
 case Builtin::BI__builtin_matrix_column_store:
@@ -15537,6 +15540,89 @@
   return CallResult;
 }
 
+ExprResult Sema::SemaBuiltinMatrixScalarOverload(CallExpr *TheCall,
+ ExprResult CallResult) {
+  if (checkArgCount(*this, TheCall, 2)) {
+return ExprError();
+  }
+
+  // First argument must be a matrix type
+  Expr *MatrixArg = TheCall->getArg(0);
+  Expr *ScalarArg = TheCall->getArg(1);
+
+  if (!MatrixArg->getType()->isMatrixType()) {
+Diag(MatrixArg->getBeginLoc(), diag::err_builtin_matrix_scalar_type_error)
+<< 0;
+return ExprError();
+  }
+
+  MatrixType const *MType =
+  cast(MatrixArg->getType().getCanonicalType());
+
+  // If the scalar type and matrix type don't match, try to cast it, otherwise,
+  // be sad
+  if (MType->getElementType() != ScalarArg->getType()) {
+ExprResult TypeCastRes = ImplicitCastExpr::Create(
+Context, MType->getElementType(), CK_IntegralToFloating, ScalarArg,
+nullptr, VK_RValue);
+
+if (!ScalarArg->getType()->isFloatingType() &&
+!ScalarArg->getType()->isIntegralType(Context)) {
+  Diag(ScalarArg->getBeginLoc(), diag::err_builtin_matrix_scalar_type_error)
+  << 1;
+  return ExprError();
+}
+
+if (TypeCastRes.isInvalid()) {
+  Diag(MatrixArg->getBeginLoc(),
+   diag::err_builtin_matrix_implicit_cast_error)
+  << MType->getElementType() << ScalarArg->getType();
+  return ExprError();
+}
+
+ScalarArg = TypeCastRes.get();
+TheCall->setArg(1, ScalarArg);
+  }
+
+  if (!MatrixArg->isRValue()) {
+ExprResult CastExprResult = ImplicitCastExpr::Create(
+Context, MatrixArg->getType(), CK_LValueToRValue, MatrixArg, nullptr,
+VK_RValue);
+assert(!CastExprResult.isInvalid() && "Matrix cast to R-value failed");
+MatrixArg = CastExprResult.get();
+TheCall->setArg(0, MatrixArg);
+  }
+
+  // Create the new function prototype
+  llvm::SmallVector ParameterTypes = {MatrixArg->getType(),
+   ScalarArg->getType()};
+
+  Expr *Callee = TheCall->getCallee();
+  DeclRefExpr *DRE = cast(Callee->IgnoreParenCasts());
+  FunctionDecl *FDecl = cast(DRE->getDecl());
+
+  // Create a new DeclRefExpr to refer to the new decl.
+  DeclRefExpr *NewDRE = DeclRefExpr::Create(
+  Context, DRE->getQualifierLoc(), SourceLocation(), FDecl,
+  /*enclosing*/ false, DRE->getLocation(), Context.BuiltinFnTy,
+  DRE->getValueKind(), nullptr, nullptr, DRE->isNonOdrUse());
+
+  // Set the callee in the CallExpr.
+  // FIXME: This loses syntactic information.
+  QualType CalleePtrTy = Context.getPointerType(FDecl->getType());
+  ExprResult PromotedCall = ImpCastExprToType(NewDRE, CalleePtrTy,
+  CK_BuiltinFnToFnPtr);
+  TheCall->setCallee(PromotedCall.get());
+
+  // Change the result type of the call to match the original value type. This
+  // is arbitrary, but the codegen for these builtins ins design to handle it
+  // gracefully.
+  TheCall->setType(MatrixArg->getType());
+
+
+  return CallResult;
+}
+
 ExprResult Sema::SemaBuiltinMatrixColumnLoadOverload(CallExpr *TheCall,
  ExprResult CallResult) {
   // Must have exactly four operands
Index: clang/lib/CodeGen/CGBuiltin.cpp
===
--- clang/lib/CodeGen/CGBuiltin.cpp
+++ clang/lib/CodeGen/CGBuiltin.cpp
@@ -2451,6 +2451,14 @@
 return RValue::get(Result);
   }
 
+  case 

[PATCH] D72782: [Matrix] Add __builtin_matrix_column_store to Clang (WIP).

2020-01-15 Thread pre-merge checks [bot] via Phabricator via cfe-commits
merge_guards_bot added a comment.

{icon question-circle color=gray} Unit tests: unknown.

{icon question-circle color=gray} clang-tidy: unknown.

{icon question-circle color=gray} clang-format: unknown.

Build artifacts 
: 
diff.json 
,
 console-log.txt 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72782



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


[PATCH] D72781: [Matrix] Add __builtin_matrix_column_load to Clang (WIP).

2020-01-15 Thread pre-merge checks [bot] via Phabricator via cfe-commits
merge_guards_bot added a comment.

{icon question-circle color=gray} Unit tests: unknown.

{icon question-circle color=gray} clang-tidy: unknown.

{icon question-circle color=gray} clang-format: unknown.

Build artifacts 
: 
diff.json 
,
 console-log.txt 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72781



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


[PATCH] D72380: [DataFlow] Factor two worklist implementations out

2020-01-15 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun added a comment.

Ping for the other reviewers :)


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

https://reviews.llvm.org/D72380



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


[PATCH] D72769: Replace CLANG_SPAWN_CC1 env var with a driver mode flag

2020-01-15 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

cc cfe-commits for completeness


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

https://reviews.llvm.org/D72769



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


[PATCH] D72304: [OpenMP]{OMPIRBuilder] Add Directives (master and critical) to OMPBuilder.

2020-01-15 Thread Fady Ghanim via Phabricator via cfe-commits
fghanim updated this revision to Diff 238301.
fghanim marked 25 inline comments as done.
fghanim added a comment.

Addressing reviewer comments

- Added regression tests
- styling
- adding asserts and todo where needed.

Also, Now `EmitInlinedRegion` will merge blocks where legal.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72304

Files:
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/test/OpenMP/critical_codegen.cpp
  clang/test/OpenMP/master_codegen.cpp
  llvm/include/llvm/Frontend/OpenMP/OMPConstants.h
  llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
  llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
  llvm/lib/Frontend/OpenMP/OMPConstants.cpp
  llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
  llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp

Index: llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp
===
--- llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp
+++ llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp
@@ -613,4 +613,164 @@
   }
 }
 
+TEST_F(OpenMPIRBuilderTest, MasterDirective) {
+  using InsertPointTy = OpenMPIRBuilder::InsertPointTy;
+  OpenMPIRBuilder OMPBuilder(*M);
+  OMPBuilder.initialize();
+  F->setName("func");
+  IRBuilder<> Builder(BB);
+
+  OpenMPIRBuilder::LocationDescription Loc({Builder.saveIP(), DL});
+
+  AllocaInst *PrivAI = nullptr;
+
+  BasicBlock *EntryBB = nullptr;
+  BasicBlock *ExitBB = nullptr;
+  BasicBlock *ThenBB = nullptr;
+
+  auto BodyGenCB = [&](InsertPointTy AllocaIP, InsertPointTy CodeGenIP,
+   BasicBlock ) {
+if (AllocaIP.isSet())
+  Builder.restoreIP(AllocaIP);
+else
+  Builder.SetInsertPoint(&*(F->getEntryBlock().getFirstInsertionPt()));
+PrivAI = Builder.CreateAlloca(F->arg_begin()->getType());
+Builder.CreateStore(F->arg_begin(), PrivAI);
+
+llvm::BasicBlock *CodeGenIPBB = CodeGenIP.getBlock();
+llvm::Instruction *CodeGenIPInst = &*CodeGenIP.getPoint();
+EXPECT_EQ(CodeGenIPBB->getTerminator(), CodeGenIPInst);
+
+Builder.restoreIP(CodeGenIP);
+
+// collect some info for checks later
+ExitBB = FiniBB.getUniqueSuccessor();
+ThenBB = Builder.GetInsertBlock();
+EntryBB = ThenBB->getUniquePredecessor();
+
+// simple instructions for body
+Value *PrivLoad = Builder.CreateLoad(PrivAI, "local.use");
+Builder.CreateICmpNE(F->arg_begin(), PrivLoad);
+  };
+
+  auto FiniCB = [&](InsertPointTy IP) {
+BasicBlock *IPBB = IP.getBlock();
+EXPECT_NE(IPBB->end(), IP.getPoint());
+  };
+
+  Builder.restoreIP(OMPBuilder.CreateMaster(Builder, BodyGenCB, FiniCB));
+  Value *EntryBBTI = EntryBB->getTerminator();
+  EXPECT_NE(EntryBBTI, nullptr);
+  EXPECT_TRUE(isa(EntryBBTI));
+  BranchInst *EntryBr = cast(EntryBB->getTerminator());
+  EXPECT_TRUE(EntryBr->isConditional());
+  EXPECT_EQ(EntryBr->getSuccessor(0), ThenBB);
+  EXPECT_EQ(ThenBB->getUniqueSuccessor(), ExitBB);
+  EXPECT_EQ(EntryBr->getSuccessor(1), ExitBB);
+
+  CmpInst *CondInst = cast(EntryBr->getCondition());
+  EXPECT_TRUE(isa(CondInst->getOperand(0)));
+
+  CallInst *MasterEntryCI = cast(CondInst->getOperand(0));
+  EXPECT_EQ(MasterEntryCI->getNumArgOperands(), 2U);
+  EXPECT_EQ(MasterEntryCI->getCalledFunction()->getName(), "__kmpc_master");
+  EXPECT_TRUE(isa(MasterEntryCI->getArgOperand(0)));
+
+  CallInst *MasterEndCI = nullptr;
+  for (auto  : *ThenBB) {
+Instruction *cur = 
+if (isa(cur)) {
+  MasterEndCI = cast(cur);
+  if (MasterEndCI->getCalledFunction()->getName() == "__kmpc_end_master")
+break;
+  else
+MasterEndCI = nullptr;
+}
+  }
+  EXPECT_NE(MasterEndCI, nullptr);
+  EXPECT_EQ(MasterEndCI->getNumArgOperands(), 2U);
+  EXPECT_TRUE(isa(MasterEndCI->getArgOperand(0)));
+  EXPECT_EQ(MasterEndCI->getArgOperand(1), MasterEntryCI->getArgOperand(1));
+}
+
+TEST_F(OpenMPIRBuilderTest, CriticalDirective) {
+  using InsertPointTy = OpenMPIRBuilder::InsertPointTy;
+  OpenMPIRBuilder OMPBuilder(*M);
+  OMPBuilder.initialize();
+  F->setName("func");
+  IRBuilder<> Builder(BB);
+
+  OpenMPIRBuilder::LocationDescription Loc({Builder.saveIP(), DL});
+
+  AllocaInst *PrivAI = Builder.CreateAlloca(F->arg_begin()->getType());
+
+  BasicBlock *EntryBB = nullptr;
+
+  auto BodyGenCB = [&](InsertPointTy AllocaIP, InsertPointTy CodeGenIP,
+   BasicBlock ) {
+// collect some info for checks later
+EntryBB = FiniBB.getUniquePredecessor();
+
+// actual start for bodyCB
+llvm::BasicBlock *CodeGenIPBB = CodeGenIP.getBlock();
+llvm::Instruction *CodeGenIPInst = &*CodeGenIP.getPoint();
+EXPECT_EQ(CodeGenIPBB->getTerminator(), CodeGenIPInst);
+EXPECT_EQ(EntryBB, CodeGenIPBB);
+
+// body begin
+Builder.restoreIP(CodeGenIP);
+Builder.CreateStore(F->arg_begin(), PrivAI);
+Value *PrivLoad = Builder.CreateLoad(PrivAI, "local.use");
+Builder.CreateICmpNE(F->arg_begin(), PrivLoad);
+  };
+
+  auto 

[PATCH] D72782: [Matrix] Add __builtin_matrix_column_store to Clang (WIP).

2020-01-15 Thread Florian Hahn via Phabricator via cfe-commits
fhahn created this revision.
Herald added a subscriber: tschuett.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D72782

Files:
  clang/include/clang/Basic/Builtins.def
  clang/include/clang/Sema/Sema.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/builtin-matrix.c

Index: clang/test/CodeGen/builtin-matrix.c
===
--- clang/test/CodeGen/builtin-matrix.c
+++ clang/test/CodeGen/builtin-matrix.c
@@ -289,5 +289,24 @@
 }
 // CHECK: declare <25 x double> @llvm.matrix.columnwise.load.v25f64.p0f64(double*, i32, i32 immarg, i32 immarg) [[READONLY:#[0-9]]]
 
+void column_store1(dx5x5_t *a, double *b) {
+  __builtin_matrix_column_store(*a, b, 10);
+
+  // CHECK-LABEL: @column_store1(
+  // CHECK-NEXT:  entry:
+  // CHECK-NEXT:%a.addr = alloca [25 x double]*, align 8
+  // CHECK-NEXT:%b.addr = alloca double*, align 8
+  // CHECK-NEXT:store [25 x double]* %a, [25 x double]** %a.addr, align 8
+  // CHECK-NEXT:store double* %b, double** %b.addr, align 8
+  // CHECK-NEXT:%0 = load [25 x double]*, [25 x double]** %a.addr, align 8
+  // CHECK-NEXT:%1 = bitcast [25 x double]* %0 to <25 x double>*
+  // CHECK-NEXT:%2 = load <25 x double>, <25 x double>* %1, align 8
+  // CHECK-NEXT:%3 = load double*, double** %b.addr, align 8
+  // CHECK-NEXT:call void @llvm.matrix.columnwise.store.v25f64.p0f64(<25 x double> %2, double* %3, i32 10, i32 5, i32 5)
+  // CHECK-NEXT:ret void
+}
+// CHECK: declare void @llvm.matrix.columnwise.store.v25f64.p0f64(<25 x double>, double* writeonly, i32, i32 immarg, i32 immarg) [[WRITEONLY:#[0-9]]]
+
 // CHECK: attributes [[READNONE]] = { nounwind readnone speculatable willreturn }
 // CHECK: attributes [[READONLY]] = { nounwind readonly willreturn }
+// CHECK: attributes [[WRITEONLY]] = { nounwind willreturn }
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -1620,6 +1620,7 @@
   case Builtin::BI__builtin_matrix_multiply:
   case Builtin::BI__builtin_matrix_transpose:
   case Builtin::BI__builtin_matrix_column_load:
+  case Builtin::BI__builtin_matrix_column_store:
 if (!getLangOpts().EnableMatrix) {
   Diag(TheCall->getBeginLoc(), diag::err_builtin_matrix_disabled);
   return ExprError();
@@ -1639,6 +1640,8 @@
   return SemaBuiltinMatrixTransposeOverload(TheCall, TheCallResult);
 case Builtin::BI__builtin_matrix_column_load:
   return SemaBuiltinMatrixColumnLoadOverload(TheCall, TheCallResult);
+case Builtin::BI__builtin_matrix_column_store:
+  return SemaBuiltinMatrixColumnStoreOverload(TheCall, TheCallResult);
 default:
   llvm_unreachable("All matrix builtins should be handled here!");
 }
@@ -15651,3 +15654,81 @@
 
   return CallResult;
 }
+
+ExprResult Sema::SemaBuiltinMatrixColumnStoreOverload(CallExpr *TheCall,
+  ExprResult CallResult) {
+  // Must have
+  // 1: Matrix to store
+  // 2: Pointer to store to
+  // 3: Stride (unsigned)
+
+  if (checkArgCount(*this, TheCall, 3))
+return ExprError();
+
+  Expr *MatrixExpr = TheCall->getArg(0);
+  Expr *DataExpr = TheCall->getArg(1);
+  Expr *StrideExpr = TheCall->getArg(2);
+
+  bool ArgError = false;
+  if (!MatrixExpr->getType()->isMatrixType()) {
+Diag(MatrixExpr->getBeginLoc(), diag::err_builtin_matrix_arg) << 0;
+ArgError = true;
+  }
+  if (!DataExpr->getType()->isPointerType()) {
+Diag(DataExpr->getBeginLoc(), diag::err_builtin_matrix_pointer_arg)
+<< 1 << 0;
+ArgError = true;
+  }
+  if (!StrideExpr->getType()->isIntegralType(Context)) {
+Diag(StrideExpr->getBeginLoc(), diag::err_builtin_matrix_scalar_int_arg)
+<< 3 << 0;
+ArgError = true;
+  }
+  if (ArgError)
+return ExprError();
+
+  // TODO: Check element type compatibility, and possibly up/down cast element
+  // types
+
+  // Cast matrix to an rvalue
+  if (!MatrixExpr->isRValue()) {
+ExprResult CastExprResult = ImplicitCastExpr::Create(
+Context, MatrixExpr->getType(), CK_LValueToRValue, MatrixExpr, nullptr,
+VK_RValue);
+assert(!CastExprResult.isInvalid() && "Matrix cast to an R-value failed");
+MatrixExpr = CastExprResult.get();
+TheCall->setArg(0, MatrixExpr);
+  }
+
+  if (!DataExpr->isRValue()) {
+ExprResult CastExprResult = ImplicitCastExpr::Create(
+Context, DataExpr->getType(), CK_LValueToRValue, DataExpr, nullptr,
+VK_RValue);
+assert(!CastExprResult.isInvalid() && "Pointer cast to R-value failed");
+DataExpr = CastExprResult.get();
+TheCall->setArg(1, DataExpr);
+  }
+
+  llvm::SmallVector ParameterTypes = {
+  MatrixExpr->getType().withConst(), DataExpr->getType(),
+  StrideExpr->getType().withConst()};
+
+ Expr *Callee = 

[PATCH] D72778: [Matrix] Add __builtin_matrix_transpose to Clang (WIP).

2020-01-15 Thread pre-merge checks [bot] via Phabricator via cfe-commits
merge_guards_bot added a comment.

{icon question-circle color=gray} Unit tests: unknown.

{icon question-circle color=gray} clang-tidy: unknown.

{icon question-circle color=gray} clang-format: unknown.

Build artifacts 
: 
diff.json 
,
 console-log.txt 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72778



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


[PATCH] D72777: [clangd] Dont display `` kinds in hover board

2020-01-15 Thread pre-merge checks [bot] via Phabricator via cfe-commits
merge_guards_bot added a comment.

{icon check-circle color=green} Unit tests: pass. 61895 tests passed, 0 failed 
and 782 were skipped.

{icon question-circle color=gray} clang-tidy: unknown.

{icon check-circle color=green} clang-format: pass.

Build artifacts 
: 
diff.json 
,
 clang-format.patch 
,
 CMakeCache.txt 
,
 console-log.txt 
,
 test-results.xml 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72777



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


[PATCH] D72761: [ARM][MVE][Intrinsics] Add VMINAQ, VMINNMAQ, VMAXAQ, VMAXNMAQ intrinsics.

2020-01-15 Thread Mark Murray via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGda9d57d2c2dc: [ARM][MVE][Intrinsics] Add VMINAQ, VMINNMAQ, 
VMAXAQ, VMAXNMAQ intrinsics. (authored by MarkMurrayARM).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72761

Files:
  clang/include/clang/Basic/arm_mve.td
  clang/test/CodeGen/arm-mve-intrinsics/vmaxaq.c
  clang/test/CodeGen/arm-mve-intrinsics/vmaxnmaq.c
  clang/test/CodeGen/arm-mve-intrinsics/vminaq.c
  clang/test/CodeGen/arm-mve-intrinsics/vminnmaq.c
  llvm/include/llvm/IR/IntrinsicsARM.td
  llvm/lib/Target/ARM/ARMInstrMVE.td
  llvm/test/CodeGen/Thumb2/mve-intrinsics/vmaxaq.ll
  llvm/test/CodeGen/Thumb2/mve-intrinsics/vmaxnmaq.ll
  llvm/test/CodeGen/Thumb2/mve-intrinsics/vminaq.ll
  llvm/test/CodeGen/Thumb2/mve-intrinsics/vminnmaq.ll

Index: llvm/test/CodeGen/Thumb2/mve-intrinsics/vminnmaq.ll
===
--- /dev/null
+++ llvm/test/CodeGen/Thumb2/mve-intrinsics/vminnmaq.ll
@@ -0,0 +1,68 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -mtriple=thumbv8.1m.main -mattr=+mve.fp -verify-machineinstrs -o - %s | FileCheck %s
+
+define arm_aapcs_vfpcc <8 x half> @test_vminnmaq_f16(<8 x half> %a, <8 x half> %b) local_unnamed_addr #0 {
+; CHECK-LABEL: test_vminnmaq_f16:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vminnma.f16 q0, q1
+; CHECK-NEXT:bx lr
+entry:
+  %0 = tail call <8 x half> @llvm.fabs.v8f16(<8 x half> %b)
+  %1 = tail call <8 x half> @llvm.minnum.v8f16(<8 x half> %a, <8 x half> %0)
+  ret <8 x half> %1
+}
+
+declare <8 x half> @llvm.fabs.v8f16(<8 x half>) #1
+
+declare <8 x half> @llvm.minnum.v8f16(<8 x half>, <8 x half>) #1
+
+define arm_aapcs_vfpcc <4 x float> @test_vminnmaq_f32(<4 x float> %a, <4 x float> %b) local_unnamed_addr #0 {
+; CHECK-LABEL: test_vminnmaq_f32:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vminnma.f32 q0, q1
+; CHECK-NEXT:bx lr
+entry:
+  %0 = tail call <4 x float> @llvm.fabs.v4f32(<4 x float> %b)
+  %1 = tail call <4 x float> @llvm.minnum.v4f32(<4 x float> %a, <4 x float> %0)
+  ret <4 x float> %1
+}
+
+declare <4 x float> @llvm.fabs.v4f32(<4 x float>) #1
+
+declare <4 x float> @llvm.minnum.v4f32(<4 x float>, <4 x float>) #1
+
+define arm_aapcs_vfpcc <8 x half> @test_vminnmaq_m_f16(<8 x half> %a, <8 x half> %b, i16 zeroext %p) local_unnamed_addr #0 {
+; CHECK-LABEL: test_vminnmaq_m_f16:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vmsr p0, r0
+; CHECK-NEXT:vpst
+; CHECK-NEXT:vminnmat.f16 q0, q1
+; CHECK-NEXT:bx lr
+entry:
+  %0 = zext i16 %p to i32
+  %1 = tail call <8 x i1> @llvm.arm.mve.pred.i2v.v8i1(i32 %0)
+  %2 = tail call <8 x half> @llvm.arm.mve.vminnma.predicated.v8f16.v8i1(<8 x half> %a, <8 x half> %b, <8 x i1> %1)
+  ret <8 x half> %2
+}
+
+declare <8 x i1> @llvm.arm.mve.pred.i2v.v8i1(i32) #2
+
+declare <8 x half> @llvm.arm.mve.vminnma.predicated.v8f16.v8i1(<8 x half>, <8 x half>, <8 x i1>) #2
+
+define arm_aapcs_vfpcc <4 x float> @test_vminnmaq_m_f32(<4 x float> %a, <4 x float> %b, i16 zeroext %p) local_unnamed_addr #0 {
+; CHECK-LABEL: test_vminnmaq_m_f32:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vmsr p0, r0
+; CHECK-NEXT:vpst
+; CHECK-NEXT:vminnmat.f32 q0, q1
+; CHECK-NEXT:bx lr
+entry:
+  %0 = zext i16 %p to i32
+  %1 = tail call <4 x i1> @llvm.arm.mve.pred.i2v.v4i1(i32 %0)
+  %2 = tail call <4 x float> @llvm.arm.mve.vminnma.predicated.v4f32.v4i1(<4 x float> %a, <4 x float> %b, <4 x i1> %1)
+  ret <4 x float> %2
+}
+
+declare <4 x i1> @llvm.arm.mve.pred.i2v.v4i1(i32) #2
+
+declare <4 x float> @llvm.arm.mve.vminnma.predicated.v4f32.v4i1(<4 x float>, <4 x float>, <4 x i1>) #2
Index: llvm/test/CodeGen/Thumb2/mve-intrinsics/vminaq.ll
===
--- /dev/null
+++ llvm/test/CodeGen/Thumb2/mve-intrinsics/vminaq.ll
@@ -0,0 +1,98 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -mtriple=thumbv8.1m.main -mattr=+mve.fp -verify-machineinstrs -o - %s | FileCheck %s
+
+define arm_aapcs_vfpcc <16 x i8> @test_vminaq_s8(<16 x i8> %a, <16 x i8> %b) local_unnamed_addr #0 {
+; CHECK-LABEL: test_vminaq_s8:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vmina.s8 q0, q1
+; CHECK-NEXT:bx lr
+entry:
+  %0 = icmp slt <16 x i8> %b, zeroinitializer
+  %1 = sub <16 x i8> zeroinitializer, %b
+  %2 = select <16 x i1> %0, <16 x i8> %1, <16 x i8> %b
+  %3 = icmp ult <16 x i8> %2, %a
+  %4 = select <16 x i1> %3, <16 x i8> %2, <16 x i8> %a
+  ret <16 x i8> %4
+}
+
+define arm_aapcs_vfpcc <8 x i16> @test_vminaq_s16(<8 x i16> %a, <8 x i16> %b) local_unnamed_addr #0 {
+; CHECK-LABEL: test_vminaq_s16:
+; CHECK:   @ %bb.0: @ %entry
+; CHECK-NEXT:vmina.s16 q0, q1
+; CHECK-NEXT:bx lr
+entry:
+  %0 = icmp slt <8 x i16> %b, zeroinitializer
+  %1 = sub <8 x i16> zeroinitializer, %b
+  

[PATCH] D72781: [Matrix] Add __builtin_matrix_column_load to Clang (WIP).

2020-01-15 Thread Florian Hahn via Phabricator via cfe-commits
fhahn created this revision.
Herald added a subscriber: tschuett.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D72781

Files:
  clang/include/clang/Basic/Builtins.def
  clang/include/clang/Sema/Sema.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/builtin-matrix.c

Index: clang/test/CodeGen/builtin-matrix.c
===
--- clang/test/CodeGen/builtin-matrix.c
+++ clang/test/CodeGen/builtin-matrix.c
@@ -271,4 +271,23 @@
 }
 // CHECK: declare <25 x double> @llvm.matrix.transpose.v25f64(<25 x double>, i32 immarg, i32 immarg) [[READNONE]]
 
+void column_load1(dx5x5_t *a, double *b) {
+  *a = __builtin_matrix_column_load(b, 5, 5, 10);
+
+  // CHECK-LABEL: @column_load1(
+  // CHECK-NEXT:  entry:
+  // CHECK-NEXT:%a.addr = alloca [25 x double]*, align 8
+  // CHECK-NEXT:%b.addr = alloca double*, align 8
+  // CHECK-NEXT:store [25 x double]* %a, [25 x double]** %a.addr, align 8
+  // CHECK-NEXT:store double* %b, double** %b.addr, align 8
+  // CHECK-NEXT:%0 = load double*, double** %b.addr, align 8
+  // CHECK-NEXT:%matrix = call <25 x double> @llvm.matrix.columnwise.load.v25f64.p0f64(double* %0, i32 10, i32 5, i32 5)
+  // CHECK-NEXT:%1 = load [25 x double]*, [25 x double]** %a.addr, align 8
+  // CHECK-NEXT:%2 = bitcast [25 x double]* %1 to <25 x double>*
+  // CHECK-NEXT:store <25 x double> %matrix, <25 x double>* %2, align 8
+  // CHECK-NEXT:ret void
+}
+// CHECK: declare <25 x double> @llvm.matrix.columnwise.load.v25f64.p0f64(double*, i32, i32 immarg, i32 immarg) [[READONLY:#[0-9]]]
+
 // CHECK: attributes [[READNONE]] = { nounwind readnone speculatable willreturn }
+// CHECK: attributes [[READONLY]] = { nounwind readonly willreturn }
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -1619,6 +1619,7 @@
   case Builtin::BI__builtin_matrix_subtract:
   case Builtin::BI__builtin_matrix_multiply:
   case Builtin::BI__builtin_matrix_transpose:
+  case Builtin::BI__builtin_matrix_column_load:
 if (!getLangOpts().EnableMatrix) {
   Diag(TheCall->getBeginLoc(), diag::err_builtin_matrix_disabled);
   return ExprError();
@@ -1636,6 +1637,8 @@
   return SemaBuiltinMatrixMultiplyOverload(TheCall, TheCallResult);
 case Builtin::BI__builtin_matrix_transpose:
   return SemaBuiltinMatrixTransposeOverload(TheCall, TheCallResult);
+case Builtin::BI__builtin_matrix_column_load:
+  return SemaBuiltinMatrixColumnLoadOverload(TheCall, TheCallResult);
 default:
   llvm_unreachable("All matrix builtins should be handled here!");
 }
@@ -15530,3 +15533,121 @@
   TheCall->setType(ResultType);
   return CallResult;
 }
+
+ExprResult Sema::SemaBuiltinMatrixColumnLoadOverload(CallExpr *TheCall,
+ ExprResult CallResult) {
+  // Must have exactly four operands
+  // 1: Pointer to data
+  // 2: Rows (constant)
+  // 3: Columns (constant)
+  // 5: Stride
+
+  // Operands have very similar semantics to glVertexAttribPointer from OpenGL.
+  // Instead of the attribute index, it is a pointer to the memory that is being
+  // loaded from Instead of size, we need the rows and columns. Note that these
+  // must be constant to construct the matrix type.
+
+  if (checkArgCount(*this, TheCall, 4))
+return ExprError();
+
+  Expr *DataExpr = TheCall->getArg(0);
+  Expr *RowsExpr = TheCall->getArg(1);
+  Expr *ColsExpr = TheCall->getArg(2);
+  Expr *StrideExpr = TheCall->getArg(3);
+
+  unsigned Rows = 0;
+  unsigned Cols = 0;
+
+  if (!(DataExpr->getType()->isPointerType() ||
+DataExpr->getType()->isArrayType())) {
+Diag(DataExpr->getBeginLoc(), diag::err_builtin_matrix_pointer_arg)
+<< 0 << 0;
+  }
+
+  bool ArgError = false;
+  // get the matrix dimensions
+  {
+llvm::APSInt Value(32);
+SourceLocation RowColErrorPos;
+
+if (!RowsExpr->isIntegerConstantExpr(Value, Context, )) {
+  Diag(RowsExpr->getBeginLoc(), diag::err_builtin_matrix_scalar_int_arg)
+  << 0 << 1;
+  ArgError = true;
+} else
+  Rows = Value.getZExtValue();
+
+if (!ColsExpr->isIntegerConstantExpr(Value, Context, )) {
+  Diag(ColsExpr->getBeginLoc(), diag::err_builtin_matrix_scalar_int_arg)
+  << 1 << 1;
+  ArgError = true;
+} else
+  Cols = Value.getZExtValue();
+  }
+  if (!StrideExpr->getType()->isIntegralType(Context)) {
+Diag(StrideExpr->getBeginLoc(), diag::err_builtin_matrix_scalar_int_arg)
+<< 3 << 1;
+ArgError = true;
+  }
+  if (ArgError)
+return ExprError();
+
+  QualType ElementType;
+
+  if (const PointerType *PTy = dyn_cast(DataExpr->getType())) {
+ElementType = PTy->getPointeeType();
+  } else if (const ArrayType *ATy = dyn_cast(DataExpr->getType())) {

[clang] 8e5018e - Replace CLANG_SPAWN_CC1 env var with a driver mode flag

2020-01-15 Thread Nico Weber via cfe-commits

Author: Nico Weber
Date: 2020-01-15T12:22:40-05:00
New Revision: 8e5018e990b701391e6c33ba85b012343df67272

URL: 
https://github.com/llvm/llvm-project/commit/8e5018e990b701391e6c33ba85b012343df67272
DIFF: 
https://github.com/llvm/llvm-project/commit/8e5018e990b701391e6c33ba85b012343df67272.diff

LOG: Replace CLANG_SPAWN_CC1 env var with a driver mode flag

Flags are clang's default UI is flags.

We can have an env var in addition to that, but in D69825 nobody has yet
mentioned why this needs an env var, so omit it for now.  If someone
needs to set the flag via env var, the existing CCC_OVERRIDE_OPTIONS
mechanism works for it (set CCC_OVERRIDE_OPTIONS=+-fno-integrated-cc1
for example).

Also mention the cc1-in-process change in the release notes.

Also spruce up the test a bit so it actually tests something :)

Differential Revision: https://reviews.llvm.org/D72769

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/include/clang/Driver/Options.td
clang/lib/Driver/Driver.cpp
clang/test/Driver/cc1-spawnprocess.c
clang/tools/driver/driver.cpp

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 66eb1268de77..e5b5438216ef 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -46,6 +46,11 @@ sections with improvements to Clang's support for those 
languages.
 Major New Features
 --
 
+- clang used to run the actual compilation in a subprocess ("clang -cc1").
+  Now compilations are done in-process by default. ``-fno-integrated-cc1``
+  restores the former behavior. The ``-v`` and ``-###`` flags will print
+  "(in-process)" when compilations are done in-process.
+
 - ...
 
 Improvements to Clang's diagnostics

diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 1218172fd5b6..abfa767afea8 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -2855,6 +2855,14 @@ def fintegrated_as : Flag<["-"], "fintegrated-as">, 
Flags<[DriverOption]>,
 def fno_integrated_as : Flag<["-"], "fno-integrated-as">,
 Flags<[CC1Option, DriverOption]>, Group,
 HelpText<"Disable the integrated assembler">;
+
+def fintegrated_cc1 : Flag<["-"], "fintegrated-cc1">,
+  Flags<[CoreOption, DriverOption]>, Group,
+  HelpText<"Run cc1 in-process">;
+def fno_integrated_cc1 : Flag<["-"], "fno-integrated-cc1">,
+ Flags<[CoreOption, DriverOption]>, Group,
+ HelpText<"Spawn a separate process for each cc1">;
+
 def : Flag<["-"], "integrated-as">, Alias, 
Flags<[DriverOption]>;
 def : Flag<["-"], "no-integrated-as">, Alias,
   Flags<[CC1Option, DriverOption]>;

diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index e718b8366df0..7ee3caaa0bce 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -1035,6 +1035,10 @@ Compilation *Driver::BuildCompilation(ArrayRef ArgList) {
   // -no-canonical-prefixes is used very early in main.
   Args.ClaimAllArgs(options::OPT_no_canonical_prefixes);
 
+  // f(no-)integated-cc1 is also used very early in main.
+  Args.ClaimAllArgs(options::OPT_fintegrated_cc1);
+  Args.ClaimAllArgs(options::OPT_fno_integrated_cc1);
+
   // Ignore -pipe.
   Args.ClaimAllArgs(options::OPT_pipe);
 

diff  --git a/clang/test/Driver/cc1-spawnprocess.c 
b/clang/test/Driver/cc1-spawnprocess.c
index c5c16ce8513f..624593895961 100644
--- a/clang/test/Driver/cc1-spawnprocess.c
+++ b/clang/test/Driver/cc1-spawnprocess.c
@@ -1,4 +1,22 @@
-// RUN: env CLANG_SPAWN_CC1= %clang -S %s -o /dev/null
-// RUN: env CLANG_SPAWN_CC1=0 %clang -S %s -o /dev/null
-// RUN: env CLANG_SPAWN_CC1=1 %clang -S %s -o /dev/null
-// RUN: env CLANG_SPAWN_CC1=test not %clang -S %s -o /dev/null
+// RUN: %clang -fintegrated-cc1 -### %s 2>&1 | FileCheck %s --check-prefix=YES
+// RUN: %clang -fno-integrated-cc1 -### %s 2>&1 | FileCheck %s 
--check-prefix=NO
+
+// RUN: %clang -fintegrated-cc1 -fno-integrated-cc1 -### %s 2>&1 \
+// RUN: | FileCheck %s --check-prefix=NO
+// RUN: %clang -fno-integrated-cc1 -fintegrated-cc1 -### %s 2>&1 \
+// RUN: | FileCheck %s --check-prefix=YES
+
+// RUN: %clang_cl -fintegrated-cc1 -### -- %s 2>&1 \
+// RUN: | FileCheck %s --check-prefix=YES
+// RUN: %clang_cl -fno-integrated-cc1 -### -- %s 2>&1 \
+// RUN: | FileCheck %s --check-prefix=NO
+
+// RUN: env CCC_OVERRIDE_OPTIONS=+-fintegrated-cc1 \
+// RUN: %clang -fintegrated-cc1 -### %s 2>&1 \
+// RUN: | FileCheck %s --check-prefix=YES
+// RUN: env CCC_OVERRIDE_OPTIONS=+-fno-integrated-cc1 \
+// RUN: %clang -fintegrated-cc1 -### %s 2>&1 \
+// RUN: | FileCheck %s --check-prefix=NO
+
+// YES: (in-process)
+// NO-NOT: (in-process)

diff  --git a/clang/tools/driver/driver.cpp b/clang/tools/driver/driver.cpp

[clang] da9d57d - [ARM][MVE][Intrinsics] Add VMINAQ, VMINNMAQ, VMAXAQ, VMAXNMAQ intrinsics.

2020-01-15 Thread Mark Murray via cfe-commits

Author: Mark Murray
Date: 2020-01-15T17:20:15Z
New Revision: da9d57d2c2dc821979490a425142afde5107066c

URL: 
https://github.com/llvm/llvm-project/commit/da9d57d2c2dc821979490a425142afde5107066c
DIFF: 
https://github.com/llvm/llvm-project/commit/da9d57d2c2dc821979490a425142afde5107066c.diff

LOG: [ARM][MVE][Intrinsics] Add VMINAQ, VMINNMAQ, VMAXAQ, VMAXNMAQ intrinsics.

Summary: Add VMINAQ, VMINNMAQ, VMAXAQ, VMAXNMAQ intrinsics and unit tests.

Reviewers: simon_tatham, miyuki, dmgreen

Subscribers: kristof.beyls, hiraditya, cfe-commits, llvm-commits

Tags: #clang, #llvm

Differential Revision: https://reviews.llvm.org/D72761

Added: 
clang/test/CodeGen/arm-mve-intrinsics/vmaxaq.c
clang/test/CodeGen/arm-mve-intrinsics/vmaxnmaq.c
clang/test/CodeGen/arm-mve-intrinsics/vminaq.c
clang/test/CodeGen/arm-mve-intrinsics/vminnmaq.c
llvm/test/CodeGen/Thumb2/mve-intrinsics/vmaxaq.ll
llvm/test/CodeGen/Thumb2/mve-intrinsics/vmaxnmaq.ll
llvm/test/CodeGen/Thumb2/mve-intrinsics/vminaq.ll
llvm/test/CodeGen/Thumb2/mve-intrinsics/vminnmaq.ll

Modified: 
clang/include/clang/Basic/arm_mve.td
llvm/include/llvm/IR/IntrinsicsARM.td
llvm/lib/Target/ARM/ARMInstrMVE.td

Removed: 




diff  --git a/clang/include/clang/Basic/arm_mve.td 
b/clang/include/clang/Basic/arm_mve.td
index 0e023b85459c..a348713b2aa3 100644
--- a/clang/include/clang/Basic/arm_mve.td
+++ b/clang/include/clang/Basic/arm_mve.td
@@ -192,6 +192,10 @@ let params = T.Int in {
 let params = T.Signed in {
   defm vqdmulhq : VectorVectorArithmetic<"qdmulh_predicated", (?), 0>;
   defm vqrdmulhq : VectorVectorArithmetic<"qrdmulh_predicated", (?), 0>;
+  def vminaq_m: Intrinsic $a, $b, $pred)>;
+  def vmaxaq_m: Intrinsic $a, $b, $pred)>;
 }
 
 let params = T.Poly, overrideKindLetter = "p" in {
@@ -203,6 +207,10 @@ let params = T.Poly, overrideKindLetter = "p" in {
 let params = T.Float in {
   defm vminnmq : VectorVectorArithmetic<"min_predicated", (? (u32 0))>;
   defm vmaxnmq : VectorVectorArithmetic<"max_predicated", (? (u32 0))>;
+  def vminnmaq_m: Intrinsic $a, $b, $pred)>;
+  def vmaxnmaq_m: Intrinsic $a, $b, $pred)>;
 }
 
 let params = T.Int in {
@@ -275,6 +283,14 @@ let params = T.Signed in {
(select (icmp_sle $a, $b), $a, $b)>;
   def vmaxq: Intrinsic;
+  def vminaq: Intrinsic;
+  def vmaxaq: Intrinsic;
 }
 let params = T.Unsigned in {
   def vminqu: Intrinsic $a, $b)>;
+ (IRIntBase<"minnum", [Vector]> $a, $b)>;
   def vmaxnmq: Intrinsic $a, $b)>;
+ (IRIntBase<"maxnum", [Vector]> $a, $b)>;
+  def vminnmaq: Intrinsic
+   $a, (IRIntBase<"fabs", [Vector]> $b))>;
+  def vmaxnmaq: Intrinsic
+   $a, (IRIntBase<"fabs", [Vector]> $b))>;
 }
 
 def vpselq: Intrinsic
+
+// CHECK-LABEL: @test_vmaxaq_s8(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[TMP0:%.*]] = icmp slt <16 x i8> [[B:%.*]], zeroinitializer
+// CHECK-NEXT:[[TMP1:%.*]] = sub <16 x i8> zeroinitializer, [[B]]
+// CHECK-NEXT:[[TMP2:%.*]] = select <16 x i1> [[TMP0]], <16 x i8> 
[[TMP1]], <16 x i8> [[B]]
+// CHECK-NEXT:[[TMP3:%.*]] = icmp ugt <16 x i8> [[TMP2]], [[A:%.*]]
+// CHECK-NEXT:[[TMP4:%.*]] = select <16 x i1> [[TMP3]], <16 x i8> 
[[TMP2]], <16 x i8> [[A]]
+// CHECK-NEXT:ret <16 x i8> [[TMP4]]
+//
+uint8x16_t test_vmaxaq_s8(uint8x16_t a, int8x16_t b)
+{
+#ifdef POLYMORPHIC
+return vmaxaq(a, b);
+#else /* POLYMORPHIC */
+return vmaxaq_s8(a, b);
+#endif /* POLYMORPHIC */
+}
+
+// CHECK-LABEL: @test_vmaxaq_s16(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[TMP0:%.*]] = icmp slt <8 x i16> [[B:%.*]], zeroinitializer
+// CHECK-NEXT:[[TMP1:%.*]] = sub <8 x i16> zeroinitializer, [[B]]
+// CHECK-NEXT:[[TMP2:%.*]] = select <8 x i1> [[TMP0]], <8 x i16> [[TMP1]], 
<8 x i16> [[B]]
+// CHECK-NEXT:[[TMP3:%.*]] = icmp ugt <8 x i16> [[TMP2]], [[A:%.*]]
+// CHECK-NEXT:[[TMP4:%.*]] = select <8 x i1> [[TMP3]], <8 x i16> [[TMP2]], 
<8 x i16> [[A]]
+// CHECK-NEXT:ret <8 x i16> [[TMP4]]
+//
+uint16x8_t test_vmaxaq_s16(uint16x8_t a, int16x8_t b)
+{
+#ifdef POLYMORPHIC
+return vmaxaq(a, b);
+#else /* POLYMORPHIC */
+return vmaxaq_s16(a, b);
+#endif /* POLYMORPHIC */
+}
+
+// CHECK-LABEL: @test_vmaxaq_s32(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[TMP0:%.*]] = icmp slt <4 x i32> [[B:%.*]], zeroinitializer
+// CHECK-NEXT:[[TMP1:%.*]] = sub <4 x i32> zeroinitializer, [[B]]
+// CHECK-NEXT:[[TMP2:%.*]] = select <4 x i1> [[TMP0]], <4 x i32> [[TMP1]], 
<4 x i32> [[B]]
+// CHECK-NEXT:[[TMP3:%.*]] = icmp ugt <4 x i32> [[TMP2]], [[A:%.*]]
+// CHECK-NEXT:[[TMP4:%.*]] = select <4 x i1> [[TMP3]], <4 x i32> [[TMP2]], 
<4 x i32> [[A]]
+// CHECK-NEXT:ret <4 x i32> [[TMP4]]
+//
+uint32x4_t test_vmaxaq_s32(uint32x4_t a, int32x4_t b)
+{
+#ifdef POLYMORPHIC
+return vmaxaq(a, b);
+#else /* 

[PATCH] D72777: [clangd] Dont display `` kinds in hover board

2020-01-15 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet created this revision.
kadircet added a reviewer: usaxena95.
Herald added subscribers: cfe-commits, arphaman, jkorous, MaskRay, 
ilya-biryukov.
Herald added a project: clang.

Currently when hovering over an `auto` or `decltype` that resolve to a
builtin-type, clangd would display `` as the kind of the symbol.

Drop that to make rendering nicer.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D72777

Files:
  clang-tools-extra/clangd/Hover.cpp
  clang-tools-extra/clangd/unittests/HoverTests.cpp


Index: clang-tools-extra/clangd/unittests/HoverTests.cpp
===
--- clang-tools-extra/clangd/unittests/HoverTests.cpp
+++ clang-tools-extra/clangd/unittests/HoverTests.cpp
@@ -1655,7 +1655,7 @@
 HI.Kind = index::SymbolKind::Unknown;
 HI.Name = "X";
   },
-  R"( X)",
+  R"(X)",
   },
   {
   [](HoverInfo ) {
Index: clang-tools-extra/clangd/Hover.cpp
===
--- clang-tools-extra/clangd/Hover.cpp
+++ clang-tools-extra/clangd/Hover.cpp
@@ -522,7 +522,8 @@
   // level 1 and 2 headers in a huge font, see
   // https://github.com/microsoft/vscode/issues/88417 for details.
   markup::Paragraph  = Output.addHeading(3);
-  Header.appendText(index::getSymbolKindString(Kind));
+  if (Kind != index::SymbolKind::Unknown)
+Header.appendText(index::getSymbolKindString(Kind));
   assert(!Name.empty() && "hover triggered on a nameless symbol");
   Header.appendCode(Name);
 


Index: clang-tools-extra/clangd/unittests/HoverTests.cpp
===
--- clang-tools-extra/clangd/unittests/HoverTests.cpp
+++ clang-tools-extra/clangd/unittests/HoverTests.cpp
@@ -1655,7 +1655,7 @@
 HI.Kind = index::SymbolKind::Unknown;
 HI.Name = "X";
   },
-  R"( X)",
+  R"(X)",
   },
   {
   [](HoverInfo ) {
Index: clang-tools-extra/clangd/Hover.cpp
===
--- clang-tools-extra/clangd/Hover.cpp
+++ clang-tools-extra/clangd/Hover.cpp
@@ -522,7 +522,8 @@
   // level 1 and 2 headers in a huge font, see
   // https://github.com/microsoft/vscode/issues/88417 for details.
   markup::Paragraph  = Output.addHeading(3);
-  Header.appendText(index::getSymbolKindString(Kind));
+  if (Kind != index::SymbolKind::Unknown)
+Header.appendText(index::getSymbolKindString(Kind));
   assert(!Name.empty() && "hover triggered on a nameless symbol");
   Header.appendCode(Name);
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D72778: [Matrix] Add __builtin_matrix_transpose to Clang (WIP).

2020-01-15 Thread Florian Hahn via Phabricator via cfe-commits
fhahn created this revision.
Herald added a subscriber: tschuett.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D72778

Files:
  clang/include/clang/Basic/Builtins.def
  clang/include/clang/Sema/Sema.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/builtin-matrix.c

Index: clang/test/CodeGen/builtin-matrix.c
===
--- clang/test/CodeGen/builtin-matrix.c
+++ clang/test/CodeGen/builtin-matrix.c
@@ -251,4 +251,24 @@
 }
 // CHECK: declare <25 x double> @llvm.matrix.multiply.v25f64.v25f64.v25f64(<25 x double>, <25 x double>, i32 immarg, i32 immarg, i32 immarg) [[READNONE:#[0-9]]]
 
+void transpose1(dx5x5_t *a, dx5x5_t *b) {
+  *a = __builtin_matrix_transpose(*b);
+
+  // CHECK-LABEL: @transpose1(
+  // CHECK-NEXT:  entry:
+  // CHECK-NEXT:%a.addr = alloca [25 x double]*, align 8
+  // CHECK-NEXT:%b.addr = alloca [25 x double]*, align 8
+  // CHECK-NEXT:store [25 x double]* %a, [25 x double]** %a.addr, align 8
+  // CHECK-NEXT:store [25 x double]* %b, [25 x double]** %b.addr, align 8
+  // CHECK-NEXT:%0 = load [25 x double]*, [25 x double]** %b.addr, align 8
+  // CHECK-NEXT:%1 = bitcast [25 x double]* %0 to <25 x double>*
+  // CHECK-NEXT:%2 = load <25 x double>, <25 x double>* %1, align 8
+  // CHECK-NEXT:%3 = call <25 x double> @llvm.matrix.transpose.v25f64(<25 x double> %2, i32 5, i32 5)
+  // CHECK-NEXT:%4 = load [25 x double]*, [25 x double]** %a.addr, align 8
+  // CHECK-NEXT:%5 = bitcast [25 x double]* %4 to <25 x double>*
+  // CHECK-NEXT:store <25 x double> %3, <25 x double>* %5, align 8
+  // CHECK-NEXT:ret void
+}
+// CHECK: declare <25 x double> @llvm.matrix.transpose.v25f64(<25 x double>, i32 immarg, i32 immarg) [[READNONE]]
+
 // CHECK: attributes [[READNONE]] = { nounwind readnone speculatable willreturn }
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -1618,6 +1618,7 @@
   case Builtin::BI__builtin_matrix_add:
   case Builtin::BI__builtin_matrix_subtract:
   case Builtin::BI__builtin_matrix_multiply:
+  case Builtin::BI__builtin_matrix_transpose:
 if (!getLangOpts().EnableMatrix) {
   Diag(TheCall->getBeginLoc(), diag::err_builtin_matrix_disabled);
   return ExprError();
@@ -1633,6 +1634,8 @@
   return SemaBuiltinMatrixEltwiseOverload(TheCall, TheCallResult);
 case Builtin::BI__builtin_matrix_multiply:
   return SemaBuiltinMatrixMultiplyOverload(TheCall, TheCallResult);
+case Builtin::BI__builtin_matrix_transpose:
+  return SemaBuiltinMatrixTransposeOverload(TheCall, TheCallResult);
 default:
   llvm_unreachable("All matrix builtins should be handled here!");
 }
@@ -15470,3 +15473,60 @@
 
   return CallResult;
 }
+
+ExprResult Sema::SemaBuiltinMatrixTransposeOverload(CallExpr *TheCall,
+ExprResult CallResult) {
+  if (checkArgCount(*this, TheCall, 1))
+return ExprError();
+
+  Expr *Arg = TheCall->getArg(0);
+
+  // Some very basic type chekcing, the parameter must be a matrix
+  if (!Arg->getType()->isMatrixType()) {
+Diag(Arg->getBeginLoc(), diag::err_builtin_matrix_arg) << 0;
+return ExprError();
+  }
+
+  MatrixType const *MType =
+  cast(Arg->getType().getCanonicalType());
+
+  unsigned R = MType->getNumRows();
+  unsigned C = MType->getNumColumns();
+  // Full Type Checking
+
+  // Set up the function prototype
+
+  if (!Arg->isRValue()) {
+ExprResult Res = ImplicitCastExpr::Create(
+Context, Arg->getType(), CK_LValueToRValue, Arg, nullptr, VK_RValue);
+assert(!Res.isInvalid() && "Matrix Cast failed");
+TheCall->setArg(0, Res.get());
+  }
+
+  Expr *Callee = TheCall->getCallee();
+  DeclRefExpr *DRE = cast(Callee->IgnoreParenCasts());
+  FunctionDecl *FDecl = cast(DRE->getDecl());
+
+  // Function Return Type
+  QualType ReturnElementType = MType->getElementType();
+  QualType ResultType = Context.getMatrixType(ReturnElementType, C, R);
+
+  // Create a new DeclRefExpr to refer to the new decl.
+  DeclRefExpr *NewDRE = DeclRefExpr::Create(
+  Context, DRE->getQualifierLoc(), SourceLocation(), FDecl,
+  /*enclosing*/ false, DRE->getLocation(), Context.BuiltinFnTy,
+  DRE->getValueKind(), nullptr, nullptr, DRE->isNonOdrUse());
+
+  // Set the callee in the CallExpr.
+  // FIXME: This loses syntactic information.
+  QualType CalleePtrTy = Context.getPointerType(FDecl->getType());
+  ExprResult PromotedCall = ImpCastExprToType(NewDRE, CalleePtrTy,
+  CK_BuiltinFnToFnPtr);
+  TheCall->setCallee(PromotedCall.get());
+
+  // Change the result type of the call to match the original value type. This
+  // is arbitrary, but the codegen for these builtins ins design to handle it
+  // 

[PATCH] D72774: [Matrix] Add __builtin_matrix_multiply to Clang (WIP).

2020-01-15 Thread pre-merge checks [bot] via Phabricator via cfe-commits
merge_guards_bot added a comment.

{icon question-circle color=gray} Unit tests: unknown.

{icon question-circle color=gray} clang-tidy: unknown.

{icon question-circle color=gray} clang-format: unknown.

Build artifacts 
: 
diff.json 
,
 console-log.txt 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72774



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


[PATCH] D72774: [Matrix] Add __builtin_matrix_multiply to Clang (WIP).

2020-01-15 Thread Florian Hahn via Phabricator via cfe-commits
fhahn created this revision.
Herald added a subscriber: tschuett.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D72774

Files:
  clang/include/clang/Basic/Builtins.def
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/builtin-matrix.c

Index: clang/test/CodeGen/builtin-matrix.c
===
--- clang/test/CodeGen/builtin-matrix.c
+++ clang/test/CodeGen/builtin-matrix.c
@@ -225,3 +225,30 @@
   // CHECK-NEXT:store <27 x i32> %11, <27 x i32>* %3, align 4
   // CHECK-NEXT:ret void
 }
+
+void multiply1(dx5x5_t *a, dx5x5_t *b, dx5x5_t *c) {
+  *a = __builtin_matrix_multiply(*b, *c);
+
+  // CHECK-LABEL: @multiply1(
+  // CHECK-NEXT:  entry:
+  // CHECK-NEXT:%a.addr = alloca [25 x double]*, align 8
+  // CHECK-NEXT:%b.addr = alloca [25 x double]*, align 8
+  // CHECK-NEXT:%c.addr = alloca [25 x double]*, align 8
+  // CHECK-NEXT:store [25 x double]* %a, [25 x double]** %a.addr, align 8
+  // CHECK-NEXT:store [25 x double]* %b, [25 x double]** %b.addr, align 8
+  // CHECK-NEXT:store [25 x double]* %c, [25 x double]** %c.addr, align 8
+  // CHECK-NEXT:%0 = load [25 x double]*, [25 x double]** %b.addr, align 8
+  // CHECK-NEXT:%1 = bitcast [25 x double]* %0 to <25 x double>*
+  // CHECK-NEXT:%2 = load <25 x double>, <25 x double>* %1, align 8
+  // CHECK-NEXT:%3 = load [25 x double]*, [25 x double]** %c.addr, align 8
+  // CHECK-NEXT:%4 = bitcast [25 x double]* %3 to <25 x double>*
+  // CHECK-NEXT:%5 = load <25 x double>, <25 x double>* %4, align 8
+  // CHECK-NEXT:%6 = call <25 x double> @llvm.matrix.multiply.v25f64.v25f64.v25f64(<25 x double> %2, <25 x double> %5, i32 5, i32 5, i32 5)
+  // CHECK-NEXT:%7 = load [25 x double]*, [25 x double]** %a.addr, align 8
+  // CHECK-NEXT:%8 = bitcast [25 x double]* %7 to <25 x double>*
+  // CHECK-NEXT:store <25 x double> %6, <25 x double>* %8, align 8
+  // CHECK-NEXT:ret void
+}
+// CHECK: declare <25 x double> @llvm.matrix.multiply.v25f64.v25f64.v25f64(<25 x double>, <25 x double>, i32 immarg, i32 immarg, i32 immarg) [[READNONE:#[0-9]]]
+
+// CHECK: attributes [[READNONE]] = { nounwind readnone speculatable willreturn }
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -1617,6 +1617,7 @@
   case Builtin::BI__builtin_matrix_extract:
   case Builtin::BI__builtin_matrix_add:
   case Builtin::BI__builtin_matrix_subtract:
+  case Builtin::BI__builtin_matrix_multiply:
 if (!getLangOpts().EnableMatrix) {
   Diag(TheCall->getBeginLoc(), diag::err_builtin_matrix_disabled);
   return ExprError();
@@ -1630,6 +1631,8 @@
 case Builtin::BI__builtin_matrix_add:
 case Builtin::BI__builtin_matrix_subtract:
   return SemaBuiltinMatrixEltwiseOverload(TheCall, TheCallResult);
+case Builtin::BI__builtin_matrix_multiply:
+  return SemaBuiltinMatrixMultiplyOverload(TheCall, TheCallResult);
 default:
   llvm_unreachable("All matrix builtins should be handled here!");
 }
@@ -15372,3 +15375,98 @@
 
   return CallResult;
 }
+
+ExprResult Sema::SemaBuiltinMatrixMultiplyOverload(CallExpr *TheCall,
+   ExprResult CallResult) {
+  if (checkArgCount(*this, TheCall, 2))
+return ExprError();
+
+  Expr *Callee = TheCall->getCallee();
+  DeclRefExpr *DRE = cast(Callee->IgnoreParenCasts());
+  FunctionDecl *FDecl = cast(DRE->getDecl());
+
+  Expr *AArg = TheCall->getArg(0);
+  Expr *BArg = TheCall->getArg(1);
+
+  bool ArgError = false;
+  // Some very basic type checking, both parameters must be matrices
+  if (!AArg->getType()->isMatrixType()) {
+Diag(AArg->getBeginLoc(), diag::err_builtin_matrix_arg) << 0;
+ArgError = true;
+  }
+  if (!BArg->getType()->isMatrixType()) {
+Diag(BArg->getBeginLoc(), diag::err_builtin_matrix_arg) << 1;
+ArgError = true;
+  }
+  if (ArgError)
+return ExprError();
+
+  MatrixType const *AMType =
+  cast(AArg->getType().getCanonicalType());
+  MatrixType const *BMType =
+  cast(BArg->getType().getCanonicalType());
+
+  unsigned m = AMType->getNumRows();
+  unsigned n = AMType->getNumColumns();
+  unsigned r = BMType->getNumColumns();
+  // Full Type Checking
+
+  // Requirements:
+  // A (m x n) * B (n x r) = AB (m x r)
+  // The A Column must match the number of rows in B
+
+  if (BMType->getNumRows() != n) {
+Diag(AArg->getBeginLoc(), diag::err_builtin_matrix_dimension_error);
+return ExprError();
+  }
+
+  // Element types of both matrices must match
+  if (AMType->getElementType() != BMType->getElementType()) {
+Diag(AArg->getBeginLoc(), diag::err_builtin_matrix_element_type)
+<< 

[clang-tools-extra] 041650d - [clangd] Extract string literals in macro arguments to unbreak gcc buildbots

2020-01-15 Thread Kadir Cetinkaya via cfe-commits

Author: Kadir Cetinkaya
Date: 2020-01-15T17:59:10+01:00
New Revision: 041650da67051266eb92b5bb07223394fe1bdab1

URL: 
https://github.com/llvm/llvm-project/commit/041650da67051266eb92b5bb07223394fe1bdab1
DIFF: 
https://github.com/llvm/llvm-project/commit/041650da67051266eb92b5bb07223394fe1bdab1.diff

LOG: [clangd] Extract string literals in macro arguments to unbreak gcc 
buildbots

Added: 


Modified: 
clang-tools-extra/clangd/unittests/HoverTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/unittests/HoverTests.cpp 
b/clang-tools-extra/clangd/unittests/HoverTests.cpp
index d30c9bfb90ff..385c064a9dce 100644
--- a/clang-tools-extra/clangd/unittests/HoverTests.cpp
+++ b/clang-tools-extra/clangd/unittests/HoverTests.cpp
@@ -1759,7 +1759,7 @@ TEST(Hover, PresentRulers) {
   HI.Value = "val";
   HI.Definition = "def";
 
-  EXPECT_EQ(HI.present().asMarkdown(), R"md(### variable `foo`  
+  llvm::StringRef ExpectedMarkdown = R"md(### variable `foo`  
 
 ---
 Value \= `val`  
@@ -1767,12 +1767,15 @@ Value \= `val`
 ---
 ```cpp
 def
-```)md");
-  EXPECT_EQ(HI.present().asPlainText(), R"pt(variable foo
+```)md";
+  EXPECT_EQ(HI.present().asMarkdown(), ExpectedMarkdown);
+
+  llvm::StringRef ExpectedPlaintext = R"pt(variable foo
 
 Value = val
 
-def)pt");
+def)pt";
+  EXPECT_EQ(HI.present().asPlainText(), ExpectedPlaintext);
 }
 
 TEST(Hover, ExprTests) {



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


[PATCH] D72723: Built-in functions for AMDGPU MFMA instructions.

2020-01-15 Thread Konstantin Pyzhov via Phabricator via cfe-commits
kpyzhov added a comment.

In D72723#1821917 , @arsenm wrote:

> Having two subtarget features for the same feature is an issue


?


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

https://reviews.llvm.org/D72723



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


[PATCH] D72773: [Matrix] Add __builtin_matrix_{add,sub} to Clang (WIP).

2020-01-15 Thread pre-merge checks [bot] via Phabricator via cfe-commits
merge_guards_bot added a comment.

{icon question-circle color=gray} Unit tests: unknown.

{icon question-circle color=gray} clang-tidy: unknown.

{icon question-circle color=gray} clang-format: unknown.

Build artifacts 
: 
diff.json 
,
 console-log.txt 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72773



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


[PATCH] D72773: [Matrix] Add __builtin_matrix_{add,sub} to Clang (WIP).

2020-01-15 Thread Florian Hahn via Phabricator via cfe-commits
fhahn created this revision.
Herald added a subscriber: tschuett.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D72773

Files:
  clang/include/clang/Basic/Builtins.def
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/builtin-matrix.c
  clang/test/CodeGenCXX/builtin-matrix.cpp
  clang/test/Sema/builtin-matrix.c
  clang/test/SemaCXX/builtin-matrix.cpp

Index: clang/test/SemaCXX/builtin-matrix.cpp
===
--- clang/test/SemaCXX/builtin-matrix.cpp
+++ clang/test/SemaCXX/builtin-matrix.cpp
@@ -42,3 +42,60 @@
   Mat1.value = *((decltype(Mat1)::matrix_t*) Ptr1);
   unsigned v1 = extract(Mat1); // expected-note {{in instantiation of function template specialization 'extract' requested here}}
 }
+
+template 
+typename MyMatrix::matrix_t add(MyMatrix , MyMatrix ) {
+  char *v1 = __builtin_matrix_add(A.value, B.value);
+  // expected-error@-1 {{cannot initialize a variable of type 'char *' with an rvalue of type 'MyMatrix::matrix_t' (aka 'unsigned int __attribute__((matrix_type(2, 2))) ')}}
+  // expected-error@-2 {{Matrix types must match}}
+  // expected-error@-3 {{Matrix types must match}}
+
+  return __builtin_matrix_add(A.value, B.value);
+  // expected-error@-1 {{Matrix types must match}}P
+  // expected-error@-2 {{Matrix types must match}}P
+}
+
+void test_add_template(unsigned *Ptr1, float *Ptr2) {
+  MyMatrix Mat1;
+  MyMatrix Mat2;
+  MyMatrix Mat3;
+  Mat1.value = *((decltype(Mat1)::matrix_t*) Ptr1);
+  unsigned v1 = add(Mat1, Mat1);
+  // expected-error@-1 {{cannot initialize a variable of type 'unsigned int' with an rvalue of type 'typename MyMatrix::matrix_t' (aka 'unsigned int __attribute__((matrix_type(2, 2))) ')}}
+  // expected-note@-2 {{in instantiation of function template specialization 'add' requested here}}
+
+  Mat1.value = add(Mat1, Mat2);
+  // expected-note@-1 {{in instantiation of function template specialization 'add' requested here}}
+
+  Mat1.value = add(Mat2, Mat3);
+  // expected-note@-1 {{in instantiation of function template specialization 'add' requested here}}
+}
+
+
+template 
+typename MyMatrix::matrix_t subtract(MyMatrix , MyMatrix ) {
+  char *v1 = __builtin_matrix_subtract(A.value, B.value);
+  // expected-error@-1 {{cannot initialize a variable of type 'char *' with an rvalue of type 'MyMatrix::matrix_t' (aka 'unsigned int __attribute__((matrix_type(2, 2))) ')}}
+  // expected-error@-2 {{Matrix types must match}}
+  // expected-error@-3 {{Matrix types must match}}
+
+  return __builtin_matrix_subtract(A.value, B.value);
+  // expected-error@-1 {{Matrix types must match}}P
+  // expected-error@-2 {{Matrix types must match}}P
+}
+
+void test_subtract_template(unsigned *Ptr1, float *Ptr2) {
+  MyMatrix Mat1;
+  MyMatrix Mat2;
+  MyMatrix Mat3;
+  Mat1.value = *((decltype(Mat1)::matrix_t*) Ptr1);
+  unsigned v1 = subtract(Mat1, Mat1);
+  // expected-error@-1 {{cannot initialize a variable of type 'unsigned int' with an rvalue of type 'typename MyMatrix::matrix_t' (aka 'unsigned int __attribute__((matrix_type(2, 2))) ')}}
+  // expected-note@-2 {{in instantiation of function template specialization 'subtract' requested here}}
+
+  Mat1.value = subtract(Mat1, Mat2);
+  // expected-note@-1 {{in instantiation of function template specialization 'subtract' requested here}}
+
+  Mat1.value = subtract(Mat2, Mat3);
+  // expected-note@-1 {{in instantiation of function template specialization 'subtract' requested here}}
+}
Index: clang/test/Sema/builtin-matrix.c
===
--- clang/test/Sema/builtin-matrix.c
+++ clang/test/Sema/builtin-matrix.c
@@ -40,3 +40,43 @@
float v4 = __builtin_matrix_extract(
   *a, 1, 1, 1); // expected-error {{too many arguments to function call, expected 3, have 4}}
 }
+
+
+typedef float sx10x5_t __attribute__((matrix_type(10, 5)));
+typedef float sx5x10_t __attribute__((matrix_type(5, 10)));
+
+void add(sx10x10_t a, sx5x10_t b, sx10x5_t c) {
+a = __builtin_matrix_add(
+b, c); // expected-error {{Matrix types must match}}
+
+a = __builtin_matrix_add( // expected-error {{assigning to 'sx10x10_t' (aka 'float __attribute__((matrix_type(10, 10))) ') from incompatible type 'sx5x10_t' (aka 'float __attribute__((matrix_type(5, 10))) ')}}
+b, b);
+
+a = __builtin_matrix_add(
+10, b); // expected-error {{First argument must be a matrix}}
+
+a = __builtin_matrix_add(
+b, ); // expected-error {{Second argument must be a matrix}}
+
+a = __builtin_matrix_add(
+,  // expected-error {{First argument must be a matrix}}
+); // expected-error {{Second argument must be a matrix}}
+}
+
+void sub(sx10x10_t a, sx5x10_t b, sx10x5_t c) {
+a = __builtin_matrix_subtract(
+b, c); // expected-error {{Matrix types 

[PATCH] D72723: Built-in functions for AMDGPU MFMA instructions.

2020-01-15 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm accepted this revision.
arsenm added a comment.
This revision is now accepted and ready to land.

LGTM


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

https://reviews.llvm.org/D72723



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


[PATCH] D72772: [Matrix] Add __builtin_matrix_extract to Clang (WIP).

2020-01-15 Thread pre-merge checks [bot] via Phabricator via cfe-commits
merge_guards_bot added a comment.

{icon question-circle color=gray} Unit tests: unknown.

{icon question-circle color=gray} clang-tidy: unknown.

{icon question-circle color=gray} clang-format: unknown.

Build artifacts 
: 
diff.json 
,
 console-log.txt 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72772



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


[PATCH] D72772: [Matrix] Add __builtin_matrix_extract to Clang (WIP).

2020-01-15 Thread Florian Hahn via Phabricator via cfe-commits
fhahn created this revision.
Herald added a subscriber: tschuett.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D72772

Files:
  clang/include/clang/Basic/Builtins.def
  clang/include/clang/Sema/Sema.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/builtin-matrix.c
  clang/test/CodeGenCXX/builtin-matrix.cpp
  clang/test/Sema/builtin-matrix.c
  clang/test/SemaCXX/builtin-matrix.cpp

Index: clang/test/SemaCXX/builtin-matrix.cpp
===
--- clang/test/SemaCXX/builtin-matrix.cpp
+++ clang/test/SemaCXX/builtin-matrix.cpp
@@ -7,6 +7,13 @@
   char *s;
 };
 
+template 
+struct MyMatrix {
+  using matrix_t = EltTy __attribute__((matrix_type(Rows, Columns)));
+
+  matrix_t value;
+};
+
 void insert(sx10x10_t *a, float f) {
   *a = __builtin_matrix_insert(
   10, // expected-error {{First argument must be a matrix}}
@@ -23,3 +30,15 @@
   *a = __builtin_matrix_insert(*a, f, // expected-error {{Row argument must be an unsigned integer}}
5u, 10.0); // expected-error {{Column argument must be an unsigned integer}}
 }
+
+template 
+EltTy extract(MyMatrix ) {
+  char *v1 = __builtin_matrix_extract(Mat.value, 1u, 0u); // expected-error {{cannot initialize a variable of type 'char *' with an rvalue of type 'unsigned int'}}
+  return __builtin_matrix_extract(Mat.value, 1u, 0u);
+}
+
+void test_extract_template(unsigned *Ptr1, float *Ptr2) {
+  MyMatrix Mat1;
+  Mat1.value = *((decltype(Mat1)::matrix_t*) Ptr1);
+  unsigned v1 = extract(Mat1); // expected-note {{in instantiation of function template specialization 'extract' requested here}}
+}
Index: clang/test/Sema/builtin-matrix.c
===
--- /dev/null
+++ clang/test/Sema/builtin-matrix.c
@@ -0,0 +1,42 @@
+// RUN: %clang_cc1 %s -fenable-matrix -pedantic -verify -triple=x86_64-apple-darwin9
+
+typedef float sx10x10_t __attribute__((matrix_type(10, 10)));
+sx10x10_t a;
+
+struct Foo {
+  char *s;
+};
+
+void insert(sx10x10_t *a, float f) {
+  *a = __builtin_matrix_insert(
+  10, // expected-error {{First argument must be a matrix}}
+  a,  // expected-error {{Row argument must be an unsigned integer}}
+  a,  // expected-error {{Column argument must be an unsigned integer}}
+  10);
+
+  int x = __builtin_matrix_insert(*a, 3u, 5u, 10.0); // expected-error {{initializing 'int' with an expression of incompatible type 'sx10x10_t' (aka 'float __attribute__((matrix_type(10, 10))) ')}}
+
+  // TODO: Should error here (index out of range).
+  *a = __builtin_matrix_insert(*a, -1u, 5u, 10.0);
+
+  // FIXME: Column argument is fine!
+  *a = __builtin_matrix_insert(*a, f, // expected-error {{Row argument must be an unsigned integer}}
+   5u, 10.0); // expected-error {{Column argument must be an unsigned integer}}
+}
+
+
+void extract(sx10x10_t *a) {
+  struct Foo v1  = __builtin_matrix_extract( // expected-error {{initializing 'struct Foo' with an expression of incompatible type 'float'}}
+  *a, 1, 1);
+
+   float v2 = __builtin_matrix_extract(
+  10,  // expected-error {{First argument must be a matrix}}
+  a,   // expected-error {{Row argument must be an unsigned integer}}
+  a);  // expected-error {{Column argument must be an unsigned integer}}
+
+   float v3 = __builtin_matrix_extract(
+  *a, 1); // expected-error {{too few arguments to function call, expected 3, have 2}}
+
+   float v4 = __builtin_matrix_extract(
+  *a, 1, 1, 1); // expected-error {{too many arguments to function call, expected 3, have 4}}
+}
Index: clang/test/CodeGenCXX/builtin-matrix.cpp
===
--- clang/test/CodeGenCXX/builtin-matrix.cpp
+++ clang/test/CodeGenCXX/builtin-matrix.cpp
@@ -70,9 +70,9 @@
   Mat.value = __builtin_matrix_insert(Mat.value, 1u, 0u, e);
 }
 
-void test_template(unsigned *Ptr1, unsigned E1, float *Ptr2, float E2) {
+void test_insert_template(unsigned *Ptr1, unsigned E1, float *Ptr2, float E2) {
 
-  // CHECK-LABEL: define void @_Z13test_templatePjjPff(i32* %Ptr1, i32 %E1, float* %Ptr2, float %E2)
+  // CHECK-LABEL: define void @_Z20test_insert_templatePjjPff(i32* %Ptr1, i32 %E1, float* %Ptr2, float %E2)
   // CHECK-NEXT:  entry:
   // CHECK-NEXT:%Ptr1.addr = alloca i32*, align 8
   // CHECK-NEXT:%E1.addr = alloca i32, align 4
@@ -148,3 +148,78 @@
   Mat2.value = *((decltype(Mat2)::matrix_t *)Ptr2);
   insert(Mat2, E2);
 }
+
+
+typedef float fx3x3_t __attribute__((matrix_type(3, 3)));
+void extract1(dx5x5_t a, fx3x3_t b, ix9x3_t c) {
+  // CHECK-LABEL: @_Z8extract1Dm5_5_dDm3_3_fDm9_3_i(
+  // CHECK-NEXT:  entry:
+  // CHECK-NEXT:%a.addr = alloca [25 x double], align 8
+  // CHECK-NEXT:%b.addr = alloca [9 x float], align 4
+  // CHECK-NEXT:%c.addr = alloca [27 x i32], align 4
+  // CHECK-NEXT:%v1 = 

  1   2   >