[PATCH] D36850: [ThinLTO] Add norecurse function attribute propagation

2021-08-26 Thread Di Mo via Phabricator via cfe-commits
modimo updated this revision to Diff 369024.
modimo marked 2 inline comments as done.
modimo added a comment.

Use prevailing for linkonce/weak. Add hasUnknownCall to model virtual and 
indirect calls


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D36850

Files:
  clang/test/CodeGen/thinlto-distributed-cfi-devirt.ll
  clang/test/CodeGen/thinlto-distributed-cfi.ll
  clang/test/CodeGen/thinlto-funcattr-prop.ll
  llvm/include/llvm/AsmParser/LLToken.h
  llvm/include/llvm/IR/GlobalValue.h
  llvm/include/llvm/IR/ModuleSummaryIndex.h
  llvm/include/llvm/LTO/LTO.h
  llvm/include/llvm/Transforms/IPO/FunctionAttrs.h
  llvm/lib/Analysis/ModuleSummaryAnalysis.cpp
  llvm/lib/AsmParser/LLLexer.cpp
  llvm/lib/AsmParser/LLParser.cpp
  llvm/lib/Bitcode/Reader/BitcodeReader.cpp
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/IR/AsmWriter.cpp
  llvm/lib/IR/ModuleSummaryIndex.cpp
  llvm/lib/LTO/LTO.cpp
  llvm/lib/LTO/LTOBackend.cpp
  llvm/lib/LTO/ThinLTOCodeGenerator.cpp
  llvm/lib/Transforms/IPO/FunctionAttrs.cpp
  llvm/test/Assembler/thinlto-summary.ll
  llvm/test/Bitcode/thinlto-function-summary-refgraph.ll
  llvm/test/Bitcode/thinlto-type-vcalls.ll
  llvm/test/ThinLTO/X86/deadstrip.ll
  llvm/test/ThinLTO/X86/dot-dumper.ll
  llvm/test/ThinLTO/X86/dot-dumper2.ll
  llvm/test/ThinLTO/X86/funcattrs-prop-exported-internal.ll
  llvm/test/ThinLTO/X86/funcattrs-prop-indirect.ll
  llvm/test/ThinLTO/X86/funcattrs-prop-undefined.ll
  llvm/test/ThinLTO/X86/funcattrs-prop-weak.ll
  llvm/test/ThinLTO/X86/funcattrs-prop.ll
  llvm/test/ThinLTO/X86/funcimport_alwaysinline.ll
  llvm/test/ThinLTO/X86/function_entry_count.ll
  llvm/test/ThinLTO/X86/linkonce_resolution_comdat.ll

Index: llvm/test/ThinLTO/X86/linkonce_resolution_comdat.ll
===
--- llvm/test/ThinLTO/X86/linkonce_resolution_comdat.ll
+++ llvm/test/ThinLTO/X86/linkonce_resolution_comdat.ll
@@ -3,15 +3,17 @@
 ; verification error.
 ; RUN: opt -module-summary %s -o %t1.bc
 ; RUN: opt -module-summary %p/Inputs/linkonce_resolution_comdat.ll -o %t2.bc
-; RUN: llvm-lto -thinlto-action=run %t1.bc %t2.bc -exported-symbol=f -exported-symbol=g -thinlto-save-temps=%t3.
+; RUN: llvm-lto -thinlto-action=run -disable-thinlto-funcattrs=0 %t1.bc %t2.bc -exported-symbol=f -exported-symbol=g -thinlto-save-temps=%t3.
 
 ; RUN: llvm-dis %t3.0.3.imported.bc -o - | FileCheck %s --check-prefix=IMPORT1
 ; RUN: llvm-dis %t3.1.3.imported.bc -o - | FileCheck %s --check-prefix=IMPORT2
 ; Copy from first module is prevailing and converted to weak_odr, copy
 ; from second module is preempted and converted to available_externally and
 ; removed from comdat.
-; IMPORT1: define weak_odr i32 @f(i8* %0) unnamed_addr comdat($c1) {
-; IMPORT2: define available_externally i32 @f(i8* %0) unnamed_addr {
+; IMPORT1: define weak_odr i32 @f(i8* %0) unnamed_addr [[ATTR:#[0-9]+]] comdat($c1) {
+; IMPORT2: define available_externally i32 @f(i8* %0) unnamed_addr [[ATTR:#[0-9]+]] {
+
+; CHECK-DAG: attributes [[ATTR]] = { norecurse nounwind }
 
 ; RUN: llvm-nm -o - < %t1.bc.thinlto.o | FileCheck %s --check-prefix=NM1
 ; NM1: W f
Index: llvm/test/ThinLTO/X86/function_entry_count.ll
===
--- llvm/test/ThinLTO/X86/function_entry_count.ll
+++ llvm/test/ThinLTO/X86/function_entry_count.ll
@@ -2,7 +2,7 @@
 ; RUN: opt -thinlto-bc %p/Inputs/function_entry_count.ll -write-relbf-to-summary -thin-link-bitcode-file=%t2.thinlink.bc -o %t2.bc
 
 ; First perform the thin link on the normal bitcode file.
-; RUN: llvm-lto2 run %t1.bc %t2.bc -o %t.o -save-temps -thinlto-synthesize-entry-counts \
+; RUN: llvm-lto2 run %t1.bc %t2.bc -o %t.o -save-temps -disable-thinlto-funcattrs=0 -thinlto-synthesize-entry-counts \
 ; RUN: -r=%t1.bc,g, \
 ; RUN: -r=%t1.bc,f,px \
 ; RUN: -r=%t1.bc,h,px \
@@ -10,15 +10,16 @@
 ; RUN: -r=%t2.bc,g,px
 ; RUN: llvm-dis -o - %t.o.1.3.import.bc | FileCheck %s
 
-; RUN: llvm-lto -thinlto-action=run -thinlto-synthesize-entry-counts -exported-symbol=f \
+; RUN: llvm-lto -thinlto-action=run -disable-thinlto-funcattrs=0 -thinlto-synthesize-entry-counts -exported-symbol=f \
 ; RUN: -exported-symbol=g -exported-symbol=h -thinlto-save-temps=%t3. %t1.bc %t2.bc
 ; RUN: llvm-dis %t3.0.3.imported.bc -o - | FileCheck %s
 
-; CHECK: define void @h() !prof ![[PROF2:[0-9]+]]
-; CHECK: define void @f(i32{{.*}}) !prof ![[PROF1:[0-9]+]]
+; CHECK: define void @h() [[ATTR:#[0-9]+]] !prof ![[PROF2:[0-9]+]]
+; CHECK: define void @f(i32{{.*}}) [[ATTR:#[0-9]+]] !prof ![[PROF1:[0-9]+]]
 ; CHECK: define available_externally void @g() !prof ![[PROF2]]
 ; CHECK-DAG: ![[PROF1]] = !{!"synthetic_function_entry_count", i64 10}
 ; CHECK-DAG: ![[PROF2]] = !{!"synthetic_function_entry_count", i64 198}
+; CHECK-DAG: attributes [[ATTR]] = { norecurse nounwind }
 
 target triple = "x86_64-unknown-linux-gnu"
 target datalayout = 

[PATCH] D36850: [ThinLTO] Add norecurse function attribute propagation

2021-08-26 Thread Di Mo via Phabricator via cfe-commits
modimo marked 3 inline comments as done.
modimo added a comment.

In D36850#2964293 , @tejohnson wrote:

> Good point on indirect calls. Rather than add a bit to the summary, can the 
> flags just be set conservatively in any function containing an indirect call 
> when we build the summaries initially? I think that would get the same effect.

That could have an issue where A calls {indirect, B} and A gets propagated upon 
from B without knowledge that the indirect call exists. Right now I've got a 
FunFlags `hasUnknownCall` which marks these as non-propagatable.

> For speculative devirtualization aka ICP, we will still be left with a 
> fallback indirect call, so it would still need to be treated conservatively. 
> The extra edges added for ICP promotion candidates shouldn't be a problem or 
> affect this.

Ah good point. I was thinking it may pessimize the propagation because of 
having to process all of these edges this is a no-go because of the fallback.

> Note that with class hierarchy analysis we can do better for virtual calls, 
> e.g. when -fwhole-program-vtables is enabled for whole program 
> devirtualization and we have the necessary whole program visibility on 
> vtables. We could potentially integrate WPD decision here. Even if we can't 
> find a single devirtualization target, we can compute the set of all possible 
> targets of virtual calls during the thin link and could use that information 
> to basically merge the attributes from all possible targets. But probably 
> best to leave that as a future refinement as it will take some additional 
> work to get that hooked up. We'd still need to be conservative for virtual 
> calls when we don't have the necessary type info (when 
> -fwhole-program-vtables not enabled or we don't have whole program visibility 
> on the vtable defs), or for non-virtual indirect calls.

Agreed, it's an engineering problem more than anything. I ran an optimistic 
build (same revisions as before, release + noinline) where indirect and virtual 
calls were assumed to always propagate (thinlto_prop_optimistic) and the effect 
in Clang self-build at least is not too large:

thinlto_base/

  "dwarfehprepare.NumCleanupLandingPadsRemaining": 217515,
  "dwarfehprepare.NumNoUnwind": 299126,
  "dwarfehprepare.NumUnwind": 332785,

thinlto_prop/

  "dwarfehprepare.NumCleanupLandingPadsRemaining": 158372,
  "dwarfehprepare.NumNoUnwind": 420918,
  "dwarfehprepare.NumUnwind": 210870,

thinlto_prop_optimistic/

  "dwarfehprepare.NumCleanupLandingPadsRemaining": 154958,
  "dwarfehprepare.NumNoUnwind": 425893,
  "dwarfehprepare.NumUnwind": 205889,

(425893-420918)/(420918-299126) = 4% boost over being conservative and correct. 
This may change in real workloads though so I added a 
`thinlto-funcattrs-optimistic-indirect` flag for easy measurement.




Comment at: llvm/lib/Transforms/IPO/FunctionAttrs.cpp:383
+  //   occur in a couple of circumstances:
+  //  a. An internal function gets imported due to its caller getting
+  //  imported, it becomes AvailableExternally

tejohnson wrote:
> I'm not sure how this case could be happening as we haven't actually done the 
> importing that would create these new available externally copies yet - that 
> happens in the LTO backends, during the thin link we just add them to import 
> lists.
I added the test funcattrs-prop-exported-internal.ll that demonstrates this. 
The summary has its internal linkage converted to external in 
[thinLTOResolvePrevailingInIndex](https://github.com/llvm/llvm-project/blob/92ce6db/llvm/lib/LTO/LTO.cpp#L436)
 then converted to AvailableExternally in 
[thinLTOResolvePrevailingGUID](https://github.com/llvm/llvm-project/blob/92ce6db/llvm/lib/LTO/LTO.cpp#L370).
 Currently being handled conservatively since a prevailing copy doesn't exist.



Comment at: llvm/lib/Transforms/IPO/FunctionAttrs.cpp:388
+  // propagating on its caller.
+  //  b. C++11 [temp.explicit]p10 can generate AvailableExternally
+  //  definitions of explicitly instanced template declarations

tejohnson wrote:
> There is no prevailing copy presumably because the prevailing copy is in a 
> native library being linked? I think these cases can be handled 
> conservatively.
Yeah the prevailing copy is in the native binary.

This is a [C++ specific 
feature](https://github.com/llvm/llvm-project/blob/92ce6db/clang/lib/AST/ASTContext.cpp#L10755)
 which has ODR and these are already being propagated/inlined from in pre-link. 
The current thinlink propagation implementation is conservative because a 
prevailing copy doesn't exist. Currently being handled conservatively since a 
prevailing copy doesn't exist.



Comment at: llvm/lib/Transforms/IPO/FunctionAttrs.cpp:419
+// Virtual calls are unknown so go conservative
+if (!FS || FS->getTypeIdInfo())
+  return CachedAttributes[VI];


[PATCH] D108787: [CUDA] Pass ExecConfig through BuildCallToMemberFunction

2021-08-26 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

need a test for non-template static member function as kernel. also need 
codegen tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108787

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


[PATCH] D93377: [Clang] Add __ibm128 type to represent ppc_fp128

2021-08-26 Thread John McCall via Phabricator via cfe-commits
rjmccall added inline comments.



Comment at: clang/include/clang/Basic/TargetInfo.h:131
+Float128,
+Ibm128
   };

qiucf wrote:
> rjmccall wrote:
> > This is necessary because it's possible to derive this type from a mode 
> > attribute?
> Yes, `__attribute__((mode(IF)))`
Okay.   I guess I agree that it makes sense to do that in a follow-up patch 
since it requires threading some extra state around.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:5159
 BT->getKind() == BuiltinType::LongDouble ||
+BT->getKind() == BuiltinType::Ibm128 ||
 (getContext().getTargetInfo().hasFloat128Type() &&

qiucf wrote:
> rjmccall wrote:
> > I hesitate to ask this, but does `__ibm128` form homogeneous aggregates 
> > with `double`s?
> > Homogeneous floating-point aggregates can have up to four IBM EXTENDED 
> > PRECISION members, four IEEE BINARY 128 QUADRUPLE PRECISION members, four 
> > _Decimal128 members, or eight members of other floating-point types. 
> > (Unions are treated as their largest member. For homogeneous unions, 
> > different union alternatives may have different sizes, provided that all 
> > union members are homogeneous with respect to each other.) They are passed 
> > in floating-point registers if parameters of that type would be passed in 
> > floating-point registers. They are passed in vector registers if parameters 
> > of that type would be passed in vector registers. They are passed as if 
> > each member was specified as a separate parameter.
> 
> Yes.
No, I mean, would an `__ibm128` in a struct with a pair of `double`s be treated 
as if it were 4 `double`s, or is it considered non-homogeneous the same way 
that a struct with e.g. 4 `float`s and 2 `double`s would be non-homogeneous?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93377

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


[PATCH] D108533: [clang] Move the soname declaration in a variable at the top of the file

2021-08-26 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay accepted this revision.
MaskRay added a comment.
This revision is now accepted and ready to land.

Looks great!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108533

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


[PATCH] D93377: [Clang] Add __ibm128 type to represent ppc_fp128

2021-08-26 Thread Qiu Chaofan via Phabricator via cfe-commits
qiucf marked 2 inline comments as done.
qiucf added inline comments.



Comment at: clang/include/clang/Basic/TargetInfo.h:131
+Float128,
+Ibm128
   };

rjmccall wrote:
> This is necessary because it's possible to derive this type from a mode 
> attribute?
Yes, `__attribute__((mode(IF)))`



Comment at: clang/lib/CodeGen/TargetInfo.cpp:5159
 BT->getKind() == BuiltinType::LongDouble ||
+BT->getKind() == BuiltinType::Ibm128 ||
 (getContext().getTargetInfo().hasFloat128Type() &&

rjmccall wrote:
> I hesitate to ask this, but does `__ibm128` form homogeneous aggregates with 
> `double`s?
> Homogeneous floating-point aggregates can have up to four IBM EXTENDED 
> PRECISION members, four IEEE BINARY 128 QUADRUPLE PRECISION members, four 
> _Decimal128 members, or eight members of other floating-point types. (Unions 
> are treated as their largest member. For homogeneous unions, different union 
> alternatives may have different sizes, provided that all union members are 
> homogeneous with respect to each other.) They are passed in floating-point 
> registers if parameters of that type would be passed in floating-point 
> registers. They are passed in vector registers if parameters of that type 
> would be passed in vector registers. They are passed as if each member was 
> specified as a separate parameter.

Yes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93377

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


[PATCH] D108797: [WIP][compiler-rt] Build fuzzer tests

2021-08-26 Thread Leonard Chan via Phabricator via cfe-commits
leonardchan created this revision.
Herald added subscribers: mgorny, dberris.
leonardchan requested review of this revision.
Herald added projects: clang, Sanitizers.
Herald added subscribers: Sanitizers, cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D108797

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake
  compiler-rt/cmake/Modules/AddCompilerRT.cmake
  compiler-rt/lib/fuzzer/tests/CMakeLists.txt


Index: compiler-rt/lib/fuzzer/tests/CMakeLists.txt
===
--- compiler-rt/lib/fuzzer/tests/CMakeLists.txt
+++ compiler-rt/lib/fuzzer/tests/CMakeLists.txt
@@ -33,7 +33,8 @@
 if(CMAKE_SYSTEM_NAME STREQUAL "Linux" AND
COMPILER_RT_LIBCXX_PATH AND
COMPILER_RT_LIBCXXABI_PATH)
-  list(APPEND LIBFUZZER_UNITTEST_CFLAGS -nostdinc++)
+  list(APPEND LIBFUZZER_UNITTEST_CFLAGS -nostdinc++ -fno-exceptions)
+  list(APPEND LIBFUZZER_UNITTEST_LINK_FLAGS -nostdlib++ -fno-exceptions)
 endif()
 
 if ("-fvisibility=hidden" IN_LIST LIBFUZZER_CFLAGS)
Index: compiler-rt/cmake/Modules/AddCompilerRT.cmake
===
--- compiler-rt/cmake/Modules/AddCompilerRT.cmake
+++ compiler-rt/cmake/Modules/AddCompilerRT.cmake
@@ -490,7 +490,7 @@
   endif()
   add_custom_command(
 OUTPUT "${output_bin}"
-COMMAND ${COMPILER_RT_TEST_COMPILER} ${TEST_OBJECTS} -o "${output_bin}"
+COMMAND ${COMPILER_RT_TEST_CXX_COMPILER} ${TEST_OBJECTS} -o "${output_bin}"
 ${TEST_LINK_FLAGS}
 DEPENDS ${TEST_DEPS}
 )
Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -122,6 +122,7 @@
 set(RUNTIMES_${target}_CMAKE_MODULE_LINKER_FLAGS "-fuse-ld=lld" CACHE 
STRING "")
 set(RUNTIMES_${target}_CMAKE_EXE_LINKER_FLAGS "-fuse-ld=lld" CACHE STRING 
"")
 set(RUNTIMES_${target}_COMPILER_RT_USE_BUILTINS_LIBRARY ON CACHE BOOL "")
+set(RUNTIMES_${target}_COMPILER_RT_CAN_EXECUTE_TESTS ON CACHE BOOL "")
 set(RUNTIMES_${target}_LIBUNWIND_ENABLE_SHARED OFF CACHE BOOL "")
 set(RUNTIMES_${target}_LIBUNWIND_USE_COMPILER_RT ON CACHE BOOL "")
 set(RUNTIMES_${target}_LIBUNWIND_INSTALL_LIBRARY OFF CACHE BOOL "")


Index: compiler-rt/lib/fuzzer/tests/CMakeLists.txt
===
--- compiler-rt/lib/fuzzer/tests/CMakeLists.txt
+++ compiler-rt/lib/fuzzer/tests/CMakeLists.txt
@@ -33,7 +33,8 @@
 if(CMAKE_SYSTEM_NAME STREQUAL "Linux" AND
COMPILER_RT_LIBCXX_PATH AND
COMPILER_RT_LIBCXXABI_PATH)
-  list(APPEND LIBFUZZER_UNITTEST_CFLAGS -nostdinc++)
+  list(APPEND LIBFUZZER_UNITTEST_CFLAGS -nostdinc++ -fno-exceptions)
+  list(APPEND LIBFUZZER_UNITTEST_LINK_FLAGS -nostdlib++ -fno-exceptions)
 endif()
 
 if ("-fvisibility=hidden" IN_LIST LIBFUZZER_CFLAGS)
Index: compiler-rt/cmake/Modules/AddCompilerRT.cmake
===
--- compiler-rt/cmake/Modules/AddCompilerRT.cmake
+++ compiler-rt/cmake/Modules/AddCompilerRT.cmake
@@ -490,7 +490,7 @@
   endif()
   add_custom_command(
 OUTPUT "${output_bin}"
-COMMAND ${COMPILER_RT_TEST_COMPILER} ${TEST_OBJECTS} -o "${output_bin}"
+COMMAND ${COMPILER_RT_TEST_CXX_COMPILER} ${TEST_OBJECTS} -o "${output_bin}"
 ${TEST_LINK_FLAGS}
 DEPENDS ${TEST_DEPS}
 )
Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -122,6 +122,7 @@
 set(RUNTIMES_${target}_CMAKE_MODULE_LINKER_FLAGS "-fuse-ld=lld" CACHE STRING "")
 set(RUNTIMES_${target}_CMAKE_EXE_LINKER_FLAGS "-fuse-ld=lld" CACHE STRING "")
 set(RUNTIMES_${target}_COMPILER_RT_USE_BUILTINS_LIBRARY ON CACHE BOOL "")
+set(RUNTIMES_${target}_COMPILER_RT_CAN_EXECUTE_TESTS ON CACHE BOOL "")
 set(RUNTIMES_${target}_LIBUNWIND_ENABLE_SHARED OFF CACHE BOOL "")
 set(RUNTIMES_${target}_LIBUNWIND_USE_COMPILER_RT ON CACHE BOOL "")
 set(RUNTIMES_${target}_LIBUNWIND_INSTALL_LIBRARY OFF CACHE BOOL "")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D105269: [X86] AVX512FP16 instructions enabling 6/6

2021-08-26 Thread LuoYuanke via Phabricator via cfe-commits
LuoYuanke added inline comments.



Comment at: llvm/lib/Target/X86/X86InstrAVX512.td:13640
+(v4f32 (OpNode VR128X:$src1, VR128X:$src2)),
+0, 0, 0, X86selects, "@earlyclobber $dst">, 
Sched<[sched.XMM]>;
+defm rm : AVX512_maskable LuoYuanke wrote:
> > I didn't see this flag for other scalar instructions, why we need it for 
> > complex instruction?
> Because all complex instructions have constrains "dst != src1 && dst != 
> src2". We use earlyclobber to avoid the dst been assigned to src1 or src2.
Got it. Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105269

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


[PATCH] D105269: [X86] AVX512FP16 instructions enabling 6/6

2021-08-26 Thread LuoYuanke via Phabricator via cfe-commits
LuoYuanke added inline comments.



Comment at: llvm/lib/Target/X86/X86InstrFoldTables.cpp:1852
+  { X86::VFCMULCPHZrr, X86::VFCMULCPHZrm, 0 },
+  { X86::VFCMULCSHZrr, X86::VFCMULCSHZrm, 
TB_NO_REVERSE },
   { X86::VFMADDPD4Yrr, X86::VFMADDPD4Ymr, 0 },

craig.topper wrote:
> LuoYuanke wrote:
> > pengfei wrote:
> > > LuoYuanke wrote:
> > > > Why FR32X version is not needed for complex scalar instructions?
> > > Do you mean complex ss/sd? We don't have these instructions.
> > No, I mean we have both X86::XXX and X86::XXX_Int for other instructions. 
> > One is FR16X which can be unfolded, one is VR128X which can't. For example, 
> > VFNMADD213SHZm and VFNMADD213SHZm_Int. 
> The VFCMULCSHZrr instructions produce two 16-bit values packed into the lower 
> 32 bits. That would mean we would need a FR32X result, but it couldn't 
> interact meaningfully with any other FR32X instruction since its really two 
> values.
> 
> I think we only have FR32/FR64 instructions for things that have generic IR 
> equivalents or that we create from other generic IR operations. Like I think 
> we have an FR32 RCP and RSQRT because we can convert float div or 1/sqrt to 
> them.
Thanks, Craig. I understand now. :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105269

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


[PATCH] D108794: Fully qualify template template parameters when printing

2021-08-26 Thread David Blaikie via Phabricator via cfe-commits
dblaikie created this revision.
dblaikie added reviewers: aaron.ballman, rtrieu.
Herald added a subscriber: arphaman.
dblaikie requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

I discovered this quirk when working on some DWARF - AST printing prints
type template parameters fully qualified, but printed template template
parameters the way they were written syntactically, or wholely
unqualified - instead, we should print them consistently with the way we
print type template parameters: fully qualified.

The one place this got weird was for partial specializations like in
ast-print-temp-class.cpp - hence the need for checking for
TemplateNameDependenceScope::DependentInstantiation template template
parameters. (not 100% sure that's the right solution to that, though -
open to ideas)


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D108794

Files:
  clang/include/clang/AST/TemplateName.h
  clang/lib/AST/NestedNameSpecifier.cpp
  clang/lib/AST/TemplateBase.cpp
  clang/lib/AST/TemplateName.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/test/CXX/drs/dr10xx.cpp
  clang/test/CXX/temp/temp.fct.spec/temp.deduct/temp.deduct.type/p9-0x.cpp
  clang/test/Index/print-type.cpp
  clang/test/Misc/diag-template.cpp
  clang/test/SemaTemplate/temp_arg_template.cpp

Index: clang/test/SemaTemplate/temp_arg_template.cpp
===
--- clang/test/SemaTemplate/temp_arg_template.cpp
+++ clang/test/SemaTemplate/temp_arg_template.cpp
@@ -59,7 +59,7 @@
 0 << a.const_ref(); // expected-error{{invalid operands to binary expression ('int' and 'X')}}
   }
 
-  void f0( Y y){ 1 << y; } // expected-note{{in instantiation of function template specialization 'N::operator<<' requested here}}
+  void f0( Y y){ 1 << y; } // expected-note{{in instantiation of function template specialization 'N::operator<<' requested here}}
 }
 
 // PR12179
Index: clang/test/Misc/diag-template.cpp
===
--- clang/test/Misc/diag-template.cpp
+++ clang/test/Misc/diag-template.cpp
@@ -34,8 +34,8 @@
 f(Q<>()).g(); // expected-error {{no member named 'g' in 'default_args::Q<>'}}
 f(Q()).g(); // expected-error {{no member named 'g' in 'default_args::Q<>'}}
 f(Q()).g(); // expected-error {{no member named 'g' in 'default_args::Q<>'}}
-f(Q()).g(); // expected-error {{no member named 'g' in 'default_args::Q'}}
-f(Q()).g(); // expected-error {{no member named 'g' in 'default_args::Q'}}
-f(Q()).g(); // expected-error {{no member named 'g' in 'default_args::Q'}}
+f(Q()).g(); // expected-error {{no member named 'g' in 'default_args::Q'}}
+f(Q()).g(); // expected-error {{no member named 'g' in 'default_args::Q'}}
+f(Q()).g(); // expected-error {{no member named 'g' in 'default_args::Q'}}
   }
 }
Index: clang/test/Index/print-type.cpp
===
--- clang/test/Index/print-type.cpp
+++ clang/test/Index/print-type.cpp
@@ -132,7 +132,7 @@
 // CHECK: TypedefDecl=OtherType:26:18 (Definition) [type=outer::inner::Bar::OtherType] [typekind=Typedef] [canonicaltype=double] [canonicaltypekind=Double] [isPOD=1]
 // CHECK: TypedefDecl=ArrayType:27:15 (Definition) [type=outer::inner::Bar::ArrayType] [typekind=Typedef] [canonicaltype=int [5]] [canonicaltypekind=ConstantArray] [isPOD=1]
 // CHECK: IntegerLiteral= [type=int] [typekind=Int] [isPOD=1]
-// CHECK: FieldDecl=baz:28:20 (Definition) [type=Baz] [typekind=Unexposed] [templateargs/3= [type=int] [typekind=Int]] [canonicaltype=outer::Baz] [canonicaltypekind=Record] [canonicaltemplateargs/3= [type=int] [typekind=Int]] [isPOD=1]
+// CHECK: FieldDecl=baz:28:20 (Definition) [type=Baz] [typekind=Unexposed] [templateargs/3= [type=int] [typekind=Int]] [canonicaltype=outer::Baz] [canonicaltypekind=Record] [canonicaltemplateargs/3= [type=int] [typekind=Int]] [isPOD=1]
 // CHECK: TemplateRef=Baz:9:8 [type=] [typekind=Invalid] [isPOD=0]
 // CHECK: IntegerLiteral= [type=int] [typekind=Int] [isPOD=1]
 // CHECK: TemplateRef=Foo:4:8 [type=] [typekind=Invalid] [isPOD=0]
Index: clang/test/CXX/temp/temp.fct.spec/temp.deduct/temp.deduct.type/p9-0x.cpp
===
--- clang/test/CXX/temp/temp.fct.spec/temp.deduct/temp.deduct.type/p9-0x.cpp
+++ clang/test/CXX/temp/temp.fct.spec/temp.deduct/temp.deduct.type/p9-0x.cpp
@@ -93,7 +93,7 @@
 }
 
 namespace DeduceWithDefaultArgs {
-  template class Container> void f(Container); // expected-note {{deduced type 'X<[...], (default) int>' of 1st parameter does not match adjusted type 'X<[...], double>' of argument [with Container = X]}}
+  template class Container> void f(Container); // expected-note {{deduced type 'X<[...], (default) int>' of 1st parameter does not match adjusted type 'X<[...], double>' of argument [with Container = DeduceWithDefaultArgs::X]}}
   template struct X 

[PATCH] D105269: [X86] AVX512FP16 instructions enabling 6/6

2021-08-26 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added inline comments.



Comment at: llvm/lib/Target/X86/X86InstrFoldTables.cpp:1852
+  { X86::VFCMULCPHZrr, X86::VFCMULCPHZrm, 0 },
+  { X86::VFCMULCSHZrr, X86::VFCMULCSHZrm, 
TB_NO_REVERSE },
   { X86::VFMADDPD4Yrr, X86::VFMADDPD4Ymr, 0 },

LuoYuanke wrote:
> pengfei wrote:
> > LuoYuanke wrote:
> > > Why FR32X version is not needed for complex scalar instructions?
> > Do you mean complex ss/sd? We don't have these instructions.
> No, I mean we have both X86::XXX and X86::XXX_Int for other instructions. One 
> is FR16X which can be unfolded, one is VR128X which can't. For example, 
> VFNMADD213SHZm and VFNMADD213SHZm_Int. 
The VFCMULCSHZrr instructions produce two 16-bit values packed into the lower 
32 bits. That would mean we would need a FR32X result, but it couldn't interact 
meaningfully with any other FR32X instruction since its really two values.

I think we only have FR32/FR64 instructions for things that have generic IR 
equivalents or that we create from other generic IR operations. Like I think we 
have an FR32 RCP and RSQRT because we can convert float div or 1/sqrt to them.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105269

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


[PATCH] D105269: [X86] AVX512FP16 instructions enabling 6/6

2021-08-26 Thread LuoYuanke via Phabricator via cfe-commits
LuoYuanke added inline comments.



Comment at: llvm/lib/Target/X86/X86InstrFoldTables.cpp:1852
+  { X86::VFCMULCPHZrr, X86::VFCMULCPHZrm, 0 },
+  { X86::VFCMULCSHZrr, X86::VFCMULCSHZrm, 
TB_NO_REVERSE },
   { X86::VFMADDPD4Yrr, X86::VFMADDPD4Ymr, 0 },

pengfei wrote:
> LuoYuanke wrote:
> > Why FR32X version is not needed for complex scalar instructions?
> Do you mean complex ss/sd? We don't have these instructions.
No, I mean we have both X86::XXX and X86::XXX_Int for other instructions. One 
is FR16X which can be unfolded, one is VR128X which can't. For example, 
VFNMADD213SHZm and VFNMADD213SHZm_Int. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105269

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


[clang] 5c24a1e - [CUDA] update constraints on NVPTX builtins to include PTX73 and 74.

2021-08-26 Thread Artem Belevich via cfe-commits

Author: Artem Belevich
Date: 2021-08-26T16:01:57-07:00
New Revision: 5c24a1e1db63f1ac3a956458df5edf87fac7be49

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

LOG: [CUDA] update constraints on NVPTX builtins to include PTX73 and 74.

Added: 


Modified: 
clang/include/clang/Basic/BuiltinsNVPTX.def

Removed: 




diff  --git a/clang/include/clang/Basic/BuiltinsNVPTX.def 
b/clang/include/clang/Basic/BuiltinsNVPTX.def
index 3c96900136a40..907a99af532c3 100644
--- a/clang/include/clang/Basic/BuiltinsNVPTX.def
+++ b/clang/include/clang/Basic/BuiltinsNVPTX.def
@@ -39,7 +39,11 @@
 #pragma push_macro("PTX70")
 #pragma push_macro("PTX71")
 #pragma push_macro("PTX72")
-#define PTX72 "ptx72"
+#pragma push_macro("PTX73")
+#pragma push_macro("PTX74")
+#define PTX74 "ptx74"
+#define PTX73 "ptx73|" PTX74
+#define PTX72 "ptx72|" PTX73
 #define PTX71 "ptx71|" PTX72
 #define PTX70 "ptx70|" PTX71
 #define PTX65 "ptx65|" PTX70
@@ -815,3 +819,5 @@ TARGET_BUILTIN(__nvvm_cp_async_wait_all, "v", "", 
AND(SM_80,PTX70))
 #pragma pop_macro("PTX70")
 #pragma pop_macro("PTX71")
 #pragma pop_macro("PTX72")
+#pragma pop_macro("PTX73")
+#pragma pop_macro("PTX74")



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


[PATCH] D108792: [M68k] Update pointer data layout

2021-08-26 Thread Jessica Clarke via Phabricator via cfe-commits
jrtc27 accepted this revision.
jrtc27 added a comment.
This revision is now accepted and ready to land.

Comments could perhaps be clearer about highlighting that 32-bit 
integers/pointers are only 16-bit aligned in the ABI as that's the weird bit, 
not the 32-bit preferred alignment


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108792

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


[PATCH] D108792: [M68k] Update pointer data layout

2021-08-26 Thread Ricky Taylor via Phabricator via cfe-commits
ricky26 created this revision.
ricky26 added reviewers: myhsu, jrtc27, nickdesaulniers, craig.topper.
Herald added a subscriber: hiraditya.
ricky26 requested review of this revision.
Herald added projects: clang, LLVM.

Fixes PR51626.

The M68k requires that all instruction, word and long word reads are
aligned to word boundaries. From the 68020 onwards, there is a
performance benefit from aligning long words to long word boundaries.

The M68k uses the same data layout for pointers and integers.

In line with this, this commit updates the pointer data layout to
match the layout already set for 32-bit integers: 32:16:32.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D108792

Files:
  clang/lib/Basic/Targets/M68k.cpp
  llvm/lib/Target/M68k/M68kTargetMachine.cpp


Index: llvm/lib/Target/M68k/M68kTargetMachine.cpp
===
--- llvm/lib/Target/M68k/M68kTargetMachine.cpp
+++ llvm/lib/Target/M68k/M68kTargetMachine.cpp
@@ -49,10 +49,13 @@
   // FIXME how to wire it with the used object format?
   Ret += "-m:e";
 
-  // M68k pointers are always 32 bit wide even for 16 bit cpus
-  Ret += "-p:32:32";
+  // M68k pointers are always 32 bit wide even for 16-bit CPUs.
+  // On at least the 68020+ with a 32-bit bus, there is a performance benefit
+  // to having 32-bit alignment.
+  Ret += "-p:32:16:32";
 
-  // M68k requires i8 to align on 2 byte boundry
+  // Bytes do not require special alignment, words are word aligned and
+  // long words are word aligned at minimum.
   Ret += "-i8:8:8-i16:16:16-i32:16:32";
 
   // FIXME no floats at the moment
Index: clang/lib/Basic/Targets/M68k.cpp
===
--- clang/lib/Basic/Targets/M68k.cpp
+++ clang/lib/Basic/Targets/M68k.cpp
@@ -37,8 +37,8 @@
   // FIXME how to wire it with the used object format?
   Layout += "-m:e";
 
-  // M68k pointers are always 32 bit wide even for 16 bit cpus
-  Layout += "-p:32:32";
+  // M68k pointers are always 32 bit wide even for 16-bit CPUs
+  Layout += "-p:32:16:32";
 
   // M68k integer data types
   Layout += "-i8:8:8-i16:16:16-i32:16:32";


Index: llvm/lib/Target/M68k/M68kTargetMachine.cpp
===
--- llvm/lib/Target/M68k/M68kTargetMachine.cpp
+++ llvm/lib/Target/M68k/M68kTargetMachine.cpp
@@ -49,10 +49,13 @@
   // FIXME how to wire it with the used object format?
   Ret += "-m:e";
 
-  // M68k pointers are always 32 bit wide even for 16 bit cpus
-  Ret += "-p:32:32";
+  // M68k pointers are always 32 bit wide even for 16-bit CPUs.
+  // On at least the 68020+ with a 32-bit bus, there is a performance benefit
+  // to having 32-bit alignment.
+  Ret += "-p:32:16:32";
 
-  // M68k requires i8 to align on 2 byte boundry
+  // Bytes do not require special alignment, words are word aligned and
+  // long words are word aligned at minimum.
   Ret += "-i8:8:8-i16:16:16-i32:16:32";
 
   // FIXME no floats at the moment
Index: clang/lib/Basic/Targets/M68k.cpp
===
--- clang/lib/Basic/Targets/M68k.cpp
+++ clang/lib/Basic/Targets/M68k.cpp
@@ -37,8 +37,8 @@
   // FIXME how to wire it with the used object format?
   Layout += "-m:e";
 
-  // M68k pointers are always 32 bit wide even for 16 bit cpus
-  Layout += "-p:32:32";
+  // M68k pointers are always 32 bit wide even for 16-bit CPUs
+  Layout += "-p:32:16:32";
 
   // M68k integer data types
   Layout += "-i8:8:8-i16:16:16-i32:16:32";
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D108423: [NFC][clang] Move IR-independent parts of target MV support to X86TargetParser.cpp

2021-08-26 Thread Andrei Elovikov via Phabricator via cfe-commits
a.elovikov added a comment.

Ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108423

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


[clang] 7bd92f5 - [AST] Pick last tentative definition as the acting definition

2021-08-26 Thread Benson Chu via cfe-commits

Author: Benson Chu
Date: 2021-08-26T16:49:54-05:00
New Revision: 7bd92f5911dc7ec54200d37552d364f87ad03dfb

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

LOG: [AST] Pick last tentative definition as the acting definition

Clang currently picks the second tentative definition when
VarDecl::getActingDefinition is called.

This can lead to attributes being dropped if they are attached to
tentative definitions that appear after the second one. This is
because VarDecl::getActingDefinition loops through VarDecl::redecls
assuming that the last tentative definition is the last element in the
iterator. However, it is the second element that would be the last
tentative definition.

This changeset modifies getActingDefinition to iterate through the
declaration chain in reverse, so that it can immediately return when
it encounters a tentative definition.

Originally the unit test for this changeset did not have a -triple
flag for the clang invocation, leading to this test being broken on
MacOS, since Mach-O does not support the section attribute.

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

Added: 
clang/test/CodeGen/attr-tentative-definition.c

Modified: 
clang/lib/AST/Decl.cpp

Removed: 




diff  --git a/clang/lib/AST/Decl.cpp b/clang/lib/AST/Decl.cpp
index aa9fba519642a..835e28c0bc9fc 100644
--- a/clang/lib/AST/Decl.cpp
+++ b/clang/lib/AST/Decl.cpp
@@ -2216,14 +2216,18 @@ VarDecl *VarDecl::getActingDefinition() {
 return nullptr;
 
   VarDecl *LastTentative = nullptr;
-  VarDecl *First = getFirstDecl();
-  for (auto I : First->redecls()) {
-Kind = I->isThisDeclarationADefinition();
+
+  // Loop through the declaration chain, starting with the most recent.
+  for (VarDecl *Decl = getMostRecentDecl(); Decl;
+   Decl = Decl->getPreviousDecl()) {
+Kind = Decl->isThisDeclarationADefinition();
 if (Kind == Definition)
   return nullptr;
-if (Kind == TentativeDefinition)
-  LastTentative = I;
+// Record the first (most recent) TentativeDefinition that is encountered.
+if (Kind == TentativeDefinition && !LastTentative)
+  LastTentative = Decl;
   }
+
   return LastTentative;
 }
 

diff  --git a/clang/test/CodeGen/attr-tentative-definition.c 
b/clang/test/CodeGen/attr-tentative-definition.c
new file mode 100644
index 0..0c49894e9bbc0
--- /dev/null
+++ b/clang/test/CodeGen/attr-tentative-definition.c
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -emit-llvm -triple x86_64-linux-unknown < %s | FileCheck %s
+
+char arr[10];
+char arr[10] __attribute__((section("datadata")));
+char arr[10] __attribute__((aligned(16)));
+
+// CHECK: @arr ={{.*}}section "datadata", align 16



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


[PATCH] D108789: [clang][NewPM] Mention that legacy PM flags are deprecated

2021-08-26 Thread Arthur Eubanks via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG6eed1fb349de: [clang][NewPM] Mention that legacy PM flags 
are deprecated (authored by aeubanks).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108789

Files:
  clang/docs/ClangCommandLineReference.rst
  clang/include/clang/Driver/Options.td


Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -1874,7 +1874,7 @@
   Alias;
 defm legacy_pass_manager : BoolOption<"f", "legacy-pass-manager",
   CodeGenOpts<"LegacyPassManager">, 
Default<"!static_cast(LLVM_ENABLE_NEW_PASS_MANAGER)">,
-  PosFlag,
+  PosFlag,
   NegFlag,
   BothFlags<[CC1Option]>>, Group;
 def fexperimental_new_pass_manager : Flag<["-"], 
"fexperimental-new-pass-manager">,
Index: clang/docs/ClangCommandLineReference.rst
===
--- clang/docs/ClangCommandLineReference.rst
+++ clang/docs/ClangCommandLineReference.rst
@@ -875,7 +875,7 @@
 
 .. option:: -flegacy-pass-manager, -fno-experimental-new-pass-manager, 
-fno-legacy-pass-manager
 
-Use the legacy pass manager in LLVM
+Use the legacy pass manager in LLVM (deprecated, to be removed in a future 
release)
 
 .. option:: -fno-crash-diagnostics
 


Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -1874,7 +1874,7 @@
   Alias;
 defm legacy_pass_manager : BoolOption<"f", "legacy-pass-manager",
   CodeGenOpts<"LegacyPassManager">, Default<"!static_cast(LLVM_ENABLE_NEW_PASS_MANAGER)">,
-  PosFlag,
+  PosFlag,
   NegFlag,
   BothFlags<[CC1Option]>>, Group;
 def fexperimental_new_pass_manager : Flag<["-"], "fexperimental-new-pass-manager">,
Index: clang/docs/ClangCommandLineReference.rst
===
--- clang/docs/ClangCommandLineReference.rst
+++ clang/docs/ClangCommandLineReference.rst
@@ -875,7 +875,7 @@
 
 .. option:: -flegacy-pass-manager, -fno-experimental-new-pass-manager, -fno-legacy-pass-manager
 
-Use the legacy pass manager in LLVM
+Use the legacy pass manager in LLVM (deprecated, to be removed in a future release)
 
 .. option:: -fno-crash-diagnostics
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 6eed1fb - [clang][NewPM] Mention that legacy PM flags are deprecated

2021-08-26 Thread Arthur Eubanks via cfe-commits

Author: Arthur Eubanks
Date: 2021-08-26T14:42:55-07:00
New Revision: 6eed1fb349de8710fba0d12a4289ac0519f23fb3

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

LOG: [clang][NewPM] Mention that legacy PM flags are deprecated

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

Added: 


Modified: 
clang/docs/ClangCommandLineReference.rst
clang/include/clang/Driver/Options.td

Removed: 




diff  --git a/clang/docs/ClangCommandLineReference.rst 
b/clang/docs/ClangCommandLineReference.rst
index dcbfba3aa836c..f42ac6dfafb74 100644
--- a/clang/docs/ClangCommandLineReference.rst
+++ b/clang/docs/ClangCommandLineReference.rst
@@ -875,7 +875,7 @@ Inline functions which are (explicitly or implicitly) 
marked inline
 
 .. option:: -flegacy-pass-manager, -fno-experimental-new-pass-manager, 
-fno-legacy-pass-manager
 
-Use the legacy pass manager in LLVM
+Use the legacy pass manager in LLVM (deprecated, to be removed in a future 
release)
 
 .. option:: -fno-crash-diagnostics
 

diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 475b0ae088140..bbf65c5507a62 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -1874,7 +1874,7 @@ def fexperimental_isel : Flag<["-"], 
"fexperimental-isel">, Group
   Alias;
 defm legacy_pass_manager : BoolOption<"f", "legacy-pass-manager",
   CodeGenOpts<"LegacyPassManager">, 
Default<"!static_cast(LLVM_ENABLE_NEW_PASS_MANAGER)">,
-  PosFlag,
+  PosFlag,
   NegFlag,
   BothFlags<[CC1Option]>>, Group;
 def fexperimental_new_pass_manager : Flag<["-"], 
"fexperimental-new-pass-manager">,



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


[clang] 82d9cb3 - [DebugInfo] convert btf_tag attrs to DI annotations for func parameters

2021-08-26 Thread Yonghong Song via cfe-commits

Author: Yonghong Song
Date: 2021-08-26T14:27:58-07:00
New Revision: 82d9cb34a2782df04975abb5a86365546ffae867

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

LOG: [DebugInfo] convert btf_tag attrs to DI annotations for func parameters

Generate btf_tag annotations for DILocalVariable. The annotations
are represented as an DINodeArray in DebugInfo.

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

Added: 
clang/test/CodeGen/attr-btf_tag-parameter.c

Modified: 
clang/lib/CodeGen/CGDebugInfo.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGDebugInfo.cpp 
b/clang/lib/CodeGen/CGDebugInfo.cpp
index 2de933f658009..5993ce8531f8f 100644
--- a/clang/lib/CodeGen/CGDebugInfo.cpp
+++ b/clang/lib/CodeGen/CGDebugInfo.cpp
@@ -4367,8 +4367,10 @@ llvm::DILocalVariable *CGDebugInfo::EmitDeclare(const 
VarDecl *VD,
   // Create the descriptor for the variable.
   llvm::DILocalVariable *D = nullptr;
   if (ArgNo) {
+llvm::DINodeArray Annotations = CollectBTFTagAnnotations(VD);
 D = DBuilder.createParameterVariable(Scope, Name, *ArgNo, Unit, Line, Ty,
- CGM.getLangOpts().Optimize, Flags);
+ CGM.getLangOpts().Optimize, Flags,
+ Annotations);
   } else {
 // For normal local variable, we will try to find out whether 'VD' is the
 // copy parameter of coroutine.

diff  --git a/clang/test/CodeGen/attr-btf_tag-parameter.c 
b/clang/test/CodeGen/attr-btf_tag-parameter.c
new file mode 100644
index 0..77ca246f68270
--- /dev/null
+++ b/clang/test/CodeGen/attr-btf_tag-parameter.c
@@ -0,0 +1,18 @@
+// REQUIRES: x86-registered-target
+// RUN: %clang -target x86_64 -g -S -emit-llvm -o - %s | FileCheck %s
+
+#define __tag1 __attribute__((btf_tag("tag1")))
+#define __tag2 __attribute__((btf_tag("tag2")))
+
+struct t1 {
+  int a;
+};
+
+int foo(struct t1 __tag1 __tag2 *arg) {
+  return arg->a;
+}
+
+// CHECK: !DILocalVariable(name: "arg", arg: 1, scope: ![[#]], file: ![[#]], 
line: [[#]], type: ![[#]], annotations: ![[ANNOT:[0-9]+]])
+// CHECK: ![[ANNOT]] = !{![[TAG1:[0-9]+]], ![[TAG2:[0-9]+]]}
+// CHECK: ![[TAG1]] = !{!"btf_tag", !"tag1"}
+// CHECK: ![[TAG2]] = !{!"btf_tag", !"tag2"}



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


[PATCH] D108789: [clang][NewPM] Mention that legacy PM flags are deprecated

2021-08-26 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay accepted this revision.
MaskRay added a comment.
This revision is now accepted and ready to land.

Looks great!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108789

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


[PATCH] D108789: [clang][NewPM] Mention that legacy PM flags are deprecated

2021-08-26 Thread Arthur Eubanks via Phabricator via cfe-commits
aeubanks created this revision.
aeubanks added a reviewer: MaskRay.
Herald added a subscriber: dang.
aeubanks requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D108789

Files:
  clang/docs/ClangCommandLineReference.rst
  clang/include/clang/Driver/Options.td


Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -1874,7 +1874,7 @@
   Alias;
 defm legacy_pass_manager : BoolOption<"f", "legacy-pass-manager",
   CodeGenOpts<"LegacyPassManager">, 
Default<"!static_cast(LLVM_ENABLE_NEW_PASS_MANAGER)">,
-  PosFlag,
+  PosFlag,
   NegFlag,
   BothFlags<[CC1Option]>>, Group;
 def fexperimental_new_pass_manager : Flag<["-"], 
"fexperimental-new-pass-manager">,
Index: clang/docs/ClangCommandLineReference.rst
===
--- clang/docs/ClangCommandLineReference.rst
+++ clang/docs/ClangCommandLineReference.rst
@@ -875,7 +875,7 @@
 
 .. option:: -flegacy-pass-manager, -fno-experimental-new-pass-manager, 
-fno-legacy-pass-manager
 
-Use the legacy pass manager in LLVM
+Use the legacy pass manager in LLVM (deprecated, to be removed in a future 
release)
 
 .. option:: -fno-crash-diagnostics
 


Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -1874,7 +1874,7 @@
   Alias;
 defm legacy_pass_manager : BoolOption<"f", "legacy-pass-manager",
   CodeGenOpts<"LegacyPassManager">, Default<"!static_cast(LLVM_ENABLE_NEW_PASS_MANAGER)">,
-  PosFlag,
+  PosFlag,
   NegFlag,
   BothFlags<[CC1Option]>>, Group;
 def fexperimental_new_pass_manager : Flag<["-"], "fexperimental-new-pass-manager">,
Index: clang/docs/ClangCommandLineReference.rst
===
--- clang/docs/ClangCommandLineReference.rst
+++ clang/docs/ClangCommandLineReference.rst
@@ -875,7 +875,7 @@
 
 .. option:: -flegacy-pass-manager, -fno-experimental-new-pass-manager, -fno-legacy-pass-manager
 
-Use the legacy pass manager in LLVM
+Use the legacy pass manager in LLVM (deprecated, to be removed in a future release)
 
 .. option:: -fno-crash-diagnostics
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D108775: [CMake] Change -DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=off to -DLLVM_ENABLE_NEW_PASS_MANAGER=off

2021-08-26 Thread Fangrui Song via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGa42bd1b56052: [CMake] Change 
-DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=off to… (authored by MaskRay).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108775

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake
  clang/cmake/caches/Fuchsia.cmake
  llvm/CMakeLists.txt
  llvm/docs/NewPassManager.rst


Index: llvm/docs/NewPassManager.rst
===
--- llvm/docs/NewPassManager.rst
+++ llvm/docs/NewPassManager.rst
@@ -449,7 +449,7 @@
 
 For the optimization pipeline, the new PM is the default PM. The legacy PM is
 available for the optimization pipeline either by setting the CMake flag
-``-DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=OFF`` when building LLVM, or by
+``-DLLVM_ENABLE_NEW_PASS_MANAGER=OFF`` when building LLVM, or by
 various compiler/linker flags, e.g. ``-flegacy-pass-manager`` for ``clang``.
 
 There will be efforts to deprecate and remove the legacy PM for the
Index: llvm/CMakeLists.txt
===
--- llvm/CMakeLists.txt
+++ llvm/CMakeLists.txt
@@ -706,8 +706,13 @@
 endif()
 option(LLVM_ENABLE_PLUGINS "Enable plugin support" 
${LLVM_ENABLE_PLUGINS_default})
 
-set(ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER TRUE CACHE BOOL
+set(LLVM_ENABLE_NEW_PASS_MANAGER TRUE CACHE BOOL
   "Enable the new pass manager by default.")
+if(NOT LLVM_ENABLE_NEW_PASS_MANAGER)
+  message(WARNING "Using the legacy pass manager for the optimization pipeline"
+  " is deprecated. The functionality will degrade over time 
and"
+  " be removed in a future release.")
+endif()
 
 include(HandleLLVMOptions)
 
@@ -846,10 +851,6 @@
   set_property(GLOBAL APPEND PROPERTY LLVM_EXPORTS tf_xla_runtime)
 endif()
 
-# Keep the legacy CMake flag ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER for
-# compatibility.
-set(LLVM_ENABLE_NEW_PASS_MANAGER ${ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER})
-
 # Configure the three LLVM configuration header files.
 configure_file(
   ${LLVM_MAIN_INCLUDE_DIR}/llvm/Config/config.h.cmake
Index: clang/cmake/caches/Fuchsia.cmake
===
--- clang/cmake/caches/Fuchsia.cmake
+++ clang/cmake/caches/Fuchsia.cmake
@@ -32,7 +32,6 @@
 set(CLANG_ENABLE_STATIC_ANALYZER ON CACHE BOOL "")
 set(CLANG_PLUGIN_SUPPORT OFF CACHE BOOL "")
 
-set(ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER ON CACHE BOOL "")
 set(ENABLE_LINKER_BUILD_ID ON CACHE BOOL "")
 set(ENABLE_X86_RELAX_RELOCATIONS ON CACHE BOOL "")
 
Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -41,7 +41,6 @@
 set(CLANG_ENABLE_STATIC_ANALYZER ON CACHE BOOL "")
 set(CLANG_PLUGIN_SUPPORT OFF CACHE BOOL "")
 
-set(ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER ON CACHE BOOL "")
 set(ENABLE_LINKER_BUILD_ID ON CACHE BOOL "")
 set(ENABLE_X86_RELAX_RELOCATIONS ON CACHE BOOL "")
 


Index: llvm/docs/NewPassManager.rst
===
--- llvm/docs/NewPassManager.rst
+++ llvm/docs/NewPassManager.rst
@@ -449,7 +449,7 @@
 
 For the optimization pipeline, the new PM is the default PM. The legacy PM is
 available for the optimization pipeline either by setting the CMake flag
-``-DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=OFF`` when building LLVM, or by
+``-DLLVM_ENABLE_NEW_PASS_MANAGER=OFF`` when building LLVM, or by
 various compiler/linker flags, e.g. ``-flegacy-pass-manager`` for ``clang``.
 
 There will be efforts to deprecate and remove the legacy PM for the
Index: llvm/CMakeLists.txt
===
--- llvm/CMakeLists.txt
+++ llvm/CMakeLists.txt
@@ -706,8 +706,13 @@
 endif()
 option(LLVM_ENABLE_PLUGINS "Enable plugin support" ${LLVM_ENABLE_PLUGINS_default})
 
-set(ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER TRUE CACHE BOOL
+set(LLVM_ENABLE_NEW_PASS_MANAGER TRUE CACHE BOOL
   "Enable the new pass manager by default.")
+if(NOT LLVM_ENABLE_NEW_PASS_MANAGER)
+  message(WARNING "Using the legacy pass manager for the optimization pipeline"
+  " is deprecated. The functionality will degrade over time and"
+  " be removed in a future release.")
+endif()
 
 include(HandleLLVMOptions)
 
@@ -846,10 +851,6 @@
   set_property(GLOBAL APPEND PROPERTY LLVM_EXPORTS tf_xla_runtime)
 endif()
 
-# Keep the legacy CMake flag ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER for
-# compatibility.
-set(LLVM_ENABLE_NEW_PASS_MANAGER ${ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER})
-
 # Configure the three LLVM configuration header files.
 configure_file(
   ${LLVM_MAIN_INCLUDE_DIR}/llvm/Config/config.h.cmake
Index: clang/cmake/caches/Fuchsia.cmake

[clang] a42bd1b - [CMake] Change -DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=off to -DLLVM_ENABLE_NEW_PASS_MANAGER=off

2021-08-26 Thread Fangrui Song via cfe-commits

Author: Fangrui Song
Date: 2021-08-26T14:25:31-07:00
New Revision: a42bd1b560524905d3b9aebcb658cf6dc9521d26

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

LOG: [CMake] Change -DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=off to 
-DLLVM_ENABLE_NEW_PASS_MANAGER=off

LLVM_ENABLE_NEW_PASS_MANAGER is set to ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER, so
-DLLVM_ENABLE_NEW_PASS_MANAGER=off has no effect.

Change the cache variable to LLVM_ENABLE_NEW_PASS_MANAGER instead.
A user opting out the new PM needs to switch from
-DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=off to
-DLLVM_ENABLE_NEW_PASS_MANAGER=off.

Also give a warning that -DLLVM_ENABLE_NEW_PASS_MANAGER=off is deprecated.

Reviewed By: aeubanks, phosek

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

Added: 


Modified: 
clang/cmake/caches/Fuchsia-stage2.cmake
clang/cmake/caches/Fuchsia.cmake
llvm/CMakeLists.txt
llvm/docs/NewPassManager.rst

Removed: 




diff  --git a/clang/cmake/caches/Fuchsia-stage2.cmake 
b/clang/cmake/caches/Fuchsia-stage2.cmake
index e58ae3ac247aa..09e8a0780c54c 100644
--- a/clang/cmake/caches/Fuchsia-stage2.cmake
+++ b/clang/cmake/caches/Fuchsia-stage2.cmake
@@ -41,7 +41,6 @@ set(CLANG_ENABLE_ARCMT OFF CACHE BOOL "")
 set(CLANG_ENABLE_STATIC_ANALYZER ON CACHE BOOL "")
 set(CLANG_PLUGIN_SUPPORT OFF CACHE BOOL "")
 
-set(ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER ON CACHE BOOL "")
 set(ENABLE_LINKER_BUILD_ID ON CACHE BOOL "")
 set(ENABLE_X86_RELAX_RELOCATIONS ON CACHE BOOL "")
 

diff  --git a/clang/cmake/caches/Fuchsia.cmake 
b/clang/cmake/caches/Fuchsia.cmake
index babc14e51a8da..a98354b7782fc 100644
--- a/clang/cmake/caches/Fuchsia.cmake
+++ b/clang/cmake/caches/Fuchsia.cmake
@@ -32,7 +32,6 @@ set(CLANG_ENABLE_ARCMT OFF CACHE BOOL "")
 set(CLANG_ENABLE_STATIC_ANALYZER ON CACHE BOOL "")
 set(CLANG_PLUGIN_SUPPORT OFF CACHE BOOL "")
 
-set(ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER ON CACHE BOOL "")
 set(ENABLE_LINKER_BUILD_ID ON CACHE BOOL "")
 set(ENABLE_X86_RELAX_RELOCATIONS ON CACHE BOOL "")
 

diff  --git a/llvm/CMakeLists.txt b/llvm/CMakeLists.txt
index 6129a9616813b..64be2f38fd01f 100644
--- a/llvm/CMakeLists.txt
+++ b/llvm/CMakeLists.txt
@@ -706,8 +706,13 @@ else()
 endif()
 option(LLVM_ENABLE_PLUGINS "Enable plugin support" 
${LLVM_ENABLE_PLUGINS_default})
 
-set(ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER TRUE CACHE BOOL
+set(LLVM_ENABLE_NEW_PASS_MANAGER TRUE CACHE BOOL
   "Enable the new pass manager by default.")
+if(NOT LLVM_ENABLE_NEW_PASS_MANAGER)
+  message(WARNING "Using the legacy pass manager for the optimization pipeline"
+  " is deprecated. The functionality will degrade over time 
and"
+  " be removed in a future release.")
+endif()
 
 include(HandleLLVMOptions)
 
@@ -846,10 +851,6 @@ if (NOT TENSORFLOW_AOT_PATH STREQUAL "")
   set_property(GLOBAL APPEND PROPERTY LLVM_EXPORTS tf_xla_runtime)
 endif()
 
-# Keep the legacy CMake flag ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER for
-# compatibility.
-set(LLVM_ENABLE_NEW_PASS_MANAGER ${ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER})
-
 # Configure the three LLVM configuration header files.
 configure_file(
   ${LLVM_MAIN_INCLUDE_DIR}/llvm/Config/config.h.cmake

diff  --git a/llvm/docs/NewPassManager.rst b/llvm/docs/NewPassManager.rst
index b3951cd76ea71..55898ef3b1fe6 100644
--- a/llvm/docs/NewPassManager.rst
+++ b/llvm/docs/NewPassManager.rst
@@ -449,7 +449,7 @@ with the legacy PM.
 
 For the optimization pipeline, the new PM is the default PM. The legacy PM is
 available for the optimization pipeline either by setting the CMake flag
-``-DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=OFF`` when building LLVM, or by
+``-DLLVM_ENABLE_NEW_PASS_MANAGER=OFF`` when building LLVM, or by
 various compiler/linker flags, e.g. ``-flegacy-pass-manager`` for ``clang``.
 
 There will be efforts to deprecate and remove the legacy PM for the



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


[PATCH] D108774: [OpenMP][FIX] Allow declare variant to work with reference types

2021-08-26 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev accepted this revision.
ABataev added a comment.
This revision is now accepted and ready to land.

LG


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108774

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


[PATCH] D108775: [CMake] Change -DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=off to -DLLVM_ENABLE_NEW_PASS_MANAGER=off

2021-08-26 Thread Petr Hosek via Phabricator via cfe-commits
phosek accepted this revision.
phosek added a comment.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108775

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


[PATCH] D108775: [CMake] Change -DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=off to -DLLVM_ENABLE_NEW_PASS_MANAGER=off

2021-08-26 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

The Fuchsia change is quite obvious. Committing. If stable for some time, will 
push to release/13.x


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108775

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


[PATCH] D106620: [Clang][LLVM] generate btf_tag annotations for func parameters

2021-08-26 Thread Yonghong Song via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG1bebc31c617d: [DebugInfo] generate btf_tag annotations for 
func parameters (authored by yonghong-song).

Changed prior to commit:
  https://reviews.llvm.org/D106620?vs=367711=368981#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106620

Files:
  llvm/include/llvm/IR/DIBuilder.h
  llvm/include/llvm/IR/DebugInfoMetadata.h
  llvm/lib/AsmParser/LLParser.cpp
  llvm/lib/Bitcode/Reader/MetadataLoader.cpp
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/IR/AsmWriter.cpp
  llvm/lib/IR/DIBuilder.cpp
  llvm/lib/IR/DebugInfoMetadata.cpp
  llvm/lib/IR/LLVMContextImpl.h
  llvm/test/Bitcode/attr-btf_tag-parameter.ll
  llvm/unittests/IR/MetadataTest.cpp

Index: llvm/unittests/IR/MetadataTest.cpp
===
--- llvm/unittests/IR/MetadataTest.cpp
+++ llvm/unittests/IR/MetadataTest.cpp
@@ -1171,7 +1171,7 @@
   DIType *Type = getDerivedType();
   DINode::DIFlags Flags = static_cast(7);
   auto *VlaExpr = DILocalVariable::get(Context, Scope, "vla_expr", File, 8,
-   Type, 2, Flags, 8);
+   Type, 2, Flags, 8, nullptr);
 
   auto *N = DISubrange::get(Context, VlaExpr, 0);
   auto Count = N->getCount();
@@ -1199,7 +1199,7 @@
   auto *UIother = ConstantAsMetadata::get(
   ConstantInt::getSigned(Type::getInt64Ty(Context), 20));
   auto *UVother = DILocalVariable::get(Context, Scope, "ubother", File, 8, Type,
-   2, Flags, 8);
+   2, Flags, 8, nullptr);
   auto *UEother = DIExpression::get(Context, {5, 6});
   auto *LIZero = ConstantAsMetadata::get(
   ConstantInt::getSigned(Type::getInt64Ty(Context), 0));
@@ -1242,13 +1242,16 @@
   DIType *Type = getDerivedType();
   DINode::DIFlags Flags = static_cast(7);
   auto *LV =
-  DILocalVariable::get(Context, Scope, "lb", File, 8, Type, 2, Flags, 8);
+  DILocalVariable::get(Context, Scope, "lb", File, 8, Type, 2, Flags, 8,
+   nullptr);
   auto *UV =
-  DILocalVariable::get(Context, Scope, "ub", File, 8, Type, 2, Flags, 8);
+  DILocalVariable::get(Context, Scope, "ub", File, 8, Type, 2, Flags, 8,
+   nullptr);
   auto *SV =
-  DILocalVariable::get(Context, Scope, "st", File, 8, Type, 2, Flags, 8);
+  DILocalVariable::get(Context, Scope, "st", File, 8, Type, 2, Flags, 8,
+   nullptr);
   auto *SVother = DILocalVariable::get(Context, Scope, "stother", File, 8, Type,
-   2, Flags, 8);
+   2, Flags, 8, nullptr);
   auto *SIother = ConstantAsMetadata::get(
   ConstantInt::getSigned(Type::getInt64Ty(Context), 20));
   auto *SEother = DIExpression::get(Context, {5, 6});
@@ -1289,7 +1292,7 @@
   auto *LIother = ConstantAsMetadata::get(
   ConstantInt::getSigned(Type::getInt64Ty(Context), 20));
   auto *LVother = DILocalVariable::get(Context, Scope, "lbother", File, 8, Type,
-   2, Flags, 8);
+   2, Flags, 8, nullptr);
 
   auto *N = DISubrange::get(Context, nullptr, LE, UE, SE);
 
@@ -1328,7 +1331,7 @@
   auto *SI = DIExpression::get(Context, {dwarf::DW_OP_consts, 4});
   auto *UIother = DIExpression::get(Context, {dwarf::DW_OP_consts, 20});
   auto *UVother = DILocalVariable::get(Context, Scope, "ubother", File, 8, Type,
-   2, Flags, 8);
+   2, Flags, 8, nullptr);
   auto *UEother = DIExpression::get(Context, {5, 6});
   auto *LIZero = DIExpression::get(Context, {dwarf::DW_OP_consts, 0});
   auto *UIZero = DIExpression::get(Context, {dwarf::DW_OP_consts, 0});
@@ -1371,13 +1374,16 @@
   DIType *Type = getDerivedType();
   DINode::DIFlags Flags = static_cast(7);
   auto *LV =
-  DILocalVariable::get(Context, Scope, "lb", File, 8, Type, 2, Flags, 8);
+  DILocalVariable::get(Context, Scope, "lb", File, 8, Type, 2, Flags, 8,
+   nullptr);
   auto *UV =
-  DILocalVariable::get(Context, Scope, "ub", File, 8, Type, 2, Flags, 8);
+  DILocalVariable::get(Context, Scope, "ub", File, 8, Type, 2, Flags, 8,
+   nullptr);
   auto *SV =
-  DILocalVariable::get(Context, Scope, "st", File, 8, Type, 2, Flags, 8);
+  DILocalVariable::get(Context, Scope, "st", File, 8, Type, 2, Flags, 8,
+   nullptr);
   auto *SVother = DILocalVariable::get(Context, Scope, "stother", File, 8, Type,
-   2, Flags, 8);
+   2, Flags, 8, nullptr);
   auto *SIother = DIExpression::get(
   Context, 

[PATCH] D108787: [CUDA] Pass ExecConfig through BuildCallToMemberFunction

2021-08-26 Thread Justin Lebar via Phabricator via cfe-commits
jlebar accepted this revision.
jlebar added a comment.
This revision is now accepted and ready to land.

Thanks, Art.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108787

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


[PATCH] D108787: [CUDA] Pass ExecConfig through BuildCallToMemberFunction

2021-08-26 Thread Artem Belevich via Phabricator via cfe-commits
tra created this revision.
tra added reviewers: jlebar, yaxunl.
Herald added subscribers: bixia, inglorion.
tra requested review of this revision.
Herald added a project: clang.

Otherwise, we fail to compile calls to CUDA kernels that are static members.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D108787

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/test/SemaCUDA/kernel-call.cu


Index: clang/test/SemaCUDA/kernel-call.cu
===
--- clang/test/SemaCUDA/kernel-call.cu
+++ clang/test/SemaCUDA/kernel-call.cu
@@ -26,3 +26,14 @@
 
   g1<<>>(42); // expected-error {{use of undeclared identifier 
'undeclared'}}
 }
+
+// Make sure we can call static member kernels.
+template  struct a {
+  template  static __global__ void Call(T);
+};
+struct b {
+  template  void d(c arg) {
+a::Call<<<0, 0>>>(arg);
+  }
+  void e() { d(1); }
+};
Index: clang/lib/Sema/SemaOverload.cpp
===
--- clang/lib/Sema/SemaOverload.cpp
+++ clang/lib/Sema/SemaOverload.cpp
@@ -14166,6 +14166,7 @@
SourceLocation LParenLoc,
MultiExprArg Args,
SourceLocation RParenLoc,
+   Expr *ExecConfig, bool IsExecConfig,
bool AllowRecovery) {
   assert(MemExprE->getType() == Context.BoundMemberTy ||
  MemExprE->getType() == Context.OverloadTy);
@@ -14361,8 +14362,8 @@
 // If overload resolution picked a static member, build a
 // non-member call based on that function.
 if (Method->isStatic()) {
-  return BuildResolvedCallExpr(MemExprE, Method, LParenLoc, Args,
-   RParenLoc);
+  return BuildResolvedCallExpr(MemExprE, Method, LParenLoc, Args, 
RParenLoc,
+   ExecConfig, IsExecConfig);
 }
 
 MemExpr = cast(MemExprE->IgnoreParens());
Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -6505,7 +6505,8 @@
 
 if (Fn->getType() == Context.BoundMemberTy) {
   return BuildCallToMemberFunction(Scope, Fn, LParenLoc, ArgExprs,
-   RParenLoc, AllowRecovery);
+   RParenLoc, ExecConfig, IsExecConfig,
+   AllowRecovery);
 }
   }
 
@@ -6524,7 +6525,8 @@
 Scope, Fn, ULE, LParenLoc, ArgExprs, RParenLoc, ExecConfig,
 /*AllowTypoCorrection=*/true, find.IsAddressOfOperand);
   return BuildCallToMemberFunction(Scope, Fn, LParenLoc, ArgExprs,
-   RParenLoc, AllowRecovery);
+   RParenLoc, ExecConfig, IsExecConfig,
+   AllowRecovery);
 }
   }
 
Index: clang/include/clang/Sema/Sema.h
===
--- clang/include/clang/Sema/Sema.h
+++ clang/include/clang/Sema/Sema.h
@@ -3885,6 +3885,8 @@
SourceLocation LParenLoc,
MultiExprArg Args,
SourceLocation RParenLoc,
+   Expr *ExecConfig = nullptr,
+   bool IsExecConfig = false,
bool AllowRecovery = false);
   ExprResult
   BuildCallToObjectOfClassType(Scope *S, Expr *Object, SourceLocation 
LParenLoc,


Index: clang/test/SemaCUDA/kernel-call.cu
===
--- clang/test/SemaCUDA/kernel-call.cu
+++ clang/test/SemaCUDA/kernel-call.cu
@@ -26,3 +26,14 @@
 
   g1<<>>(42); // expected-error {{use of undeclared identifier 'undeclared'}}
 }
+
+// Make sure we can call static member kernels.
+template  struct a {
+  template  static __global__ void Call(T);
+};
+struct b {
+  template  void d(c arg) {
+a::Call<<<0, 0>>>(arg);
+  }
+  void e() { d(1); }
+};
Index: clang/lib/Sema/SemaOverload.cpp
===
--- clang/lib/Sema/SemaOverload.cpp
+++ clang/lib/Sema/SemaOverload.cpp
@@ -14166,6 +14166,7 @@
SourceLocation LParenLoc,
MultiExprArg Args,
SourceLocation RParenLoc,
+   Expr *ExecConfig, bool IsExecConfig,
bool AllowRecovery) {
   assert(MemExprE->getType() == Context.BoundMemberTy ||
  MemExprE->getType() == Context.OverloadTy);
@@ 

[PATCH] D108774: [OpenMP][FIX] Allow declare variant to work with reference types

2021-08-26 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added a comment.

I think I addressed your concerns with the 2 additional checks and more test 
coverage, as always, return 0 are the functions it should call.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108774

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


[PATCH] D108774: [OpenMP][FIX] Allow declare variant to work with reference types

2021-08-26 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert updated this revision to Diff 368978.
jdoerfert added a comment.

Add OpenMP check, add L/RValue check, add tests for multiple combinations of & 
vs &&


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108774

Files:
  clang/lib/AST/ASTContext.cpp
  clang/test/AST/ast-dump-openmp-begin-declare-variant_reference.cpp

Index: clang/test/AST/ast-dump-openmp-begin-declare-variant_reference.cpp
===
--- /dev/null
+++ clang/test/AST/ast-dump-openmp-begin-declare-variant_reference.cpp
@@ -0,0 +1,414 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fopenmp -verify -ast-dump %s   | FileCheck %s
+// expected-no-diagnostics
+
+// Our very own std::move, copied from libcxx.
+template  struct remove_reference { typedef _Tp type; };
+template  struct remove_reference<_Tp &> { typedef _Tp type; };
+template  struct remove_reference<_Tp &&> { typedef _Tp type; };
+
+template 
+inline typename remove_reference<_Tp>::type &&
+move(_Tp &&__t) {
+  typedef typename remove_reference<_Tp>::type _Up;
+  return static_cast<_Up &&>(__t);
+}
+// ---
+
+int Good, Bad;
+int _before() {
+  return Bad;
+}
+int also_before(float &&) {
+  return 0;
+}
+
+#pragma omp begin declare variant match(implementation = {vendor(score(100) \
+ : llvm)})
+int also_after(void) {
+  return 1;
+}
+int also_after(int &) {
+  return 2;
+}
+// This one does overload the int(*)(double&) version!
+int also_after(double &) {
+  return 0;
+}
+int also_after(double &&) {
+  return 3;
+}
+int also_after(short &) {
+  return 5;
+}
+int also_after(short &&) {
+  return 0;
+}
+#pragma omp end declare variant
+#pragma omp begin declare variant match(implementation = {vendor(score(0) \
+ : llvm)})
+// This one does overload the int&(*)(void) version!
+int _before() {
+  return Good;
+}
+// This one does *not* overload the int(*)(float&&) version!
+int also_before(float &) {
+  return 6;
+}
+#pragma omp end declare variant
+
+int also_after(void) {
+  return 7;
+}
+int also_after(int) {
+  return 8;
+}
+int also_after(double &) {
+  return 9;
+}
+int also_after(short &&) {
+  return 10;
+}
+
+int test1() {
+  // Should return 0.
+  double d;
+  return also_after(d);
+}
+
+int test2() {
+  // Should return 0.
+  return _before() == 
+}
+
+int test3(float &) {
+  // Should return 0.
+  return also_before(move(f));
+}
+
+int test4(short &) {
+  // Should return 0.
+  return also_after(move(s));
+}
+
+int test(float &, short &) {
+  // Should return 0.
+  return test1() + test2() + test3(move(f)) + test4(move(s));
+}
+
+// CHECK:  |-ClassTemplateDecl [[ADDR_0:0x[a-z0-9]*]] <{{.*}}, col:66> col:29 remove_reference
+// CHECK-NEXT: | |-TemplateTypeParmDecl [[ADDR_1:0x[a-z0-9]*]]  col:17 referenced class depth 0 index 0 _Tp
+// CHECK-NEXT: | |-CXXRecordDecl [[ADDR_2:0x[a-z0-9]*]]  col:29 struct remove_reference definition
+// CHECK-NEXT: | | |-DefinitionData empty aggregate standard_layout trivially_copyable pod trivial literal has_constexpr_non_copy_move_ctor can_const_default_init
+// CHECK-NEXT: | | | |-DefaultConstructor exists trivial constexpr needs_implicit defaulted_is_constexpr
+// CHECK-NEXT: | | | |-CopyConstructor simple trivial has_const_param needs_implicit implicit_has_const_param
+// CHECK-NEXT: | | | |-MoveConstructor exists simple trivial needs_implicit
+// CHECK-NEXT: | | | |-CopyAssignment simple trivial has_const_param needs_implicit implicit_has_const_param
+// CHECK-NEXT: | | | |-MoveAssignment exists simple trivial needs_implicit
+// CHECK-NEXT: | | | `-Destructor simple irrelevant trivial needs_implicit
+// CHECK-NEXT: | | |-CXXRecordDecl [[ADDR_3:0x[a-z0-9]*]]  col:29 implicit struct remove_reference
+// CHECK-NEXT: | | `-TypedefDecl [[ADDR_4:0x[a-z0-9]*]]  col:60 type '_Tp'
+// CHECK-NEXT: | |   `-TemplateTypeParmType [[ADDR_5:0x[a-z0-9]*]] '_Tp' dependent depth 0 index 0
+// CHECK-NEXT: | | `-TemplateTypeParm [[ADDR_1]] '_Tp'
+// CHECK-NEXT: | |-ClassTemplateSpecializationDecl [[ADDR_6:0x[a-z0-9]*]]  col:29 struct remove_reference definition
+// CHECK-NEXT: | | |-DefinitionData pass_in_registers empty aggregate standard_layout trivially_copyable pod trivial literal has_constexpr_non_copy_move_ctor can_const_default_init
+// CHECK-NEXT: | | | |-DefaultConstructor exists trivial constexpr needs_implicit defaulted_is_constexpr
+// CHECK-NEXT: | | | |-CopyConstructor simple trivial has_const_param needs_implicit implicit_has_const_param
+// CHECK-NEXT: | | | |-MoveConstructor exists simple trivial needs_implicit
+// CHECK-NEXT: | | | |-CopyAssignment simple trivial has_const_param needs_implicit implicit_has_const_param
+// CHECK-NEXT: | | | |-MoveAssignment exists simple trivial needs_implicit
+// CHECK-NEXT: | | | `-Destructor simple irrelevant trivial 

[PATCH] D108775: [CMake] Change -DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=off to -DLLVM_ENABLE_NEW_PASS_MANAGER=off

2021-08-26 Thread Arthur Eubanks via Phabricator via cfe-commits
aeubanks added a comment.

lg, thanks for doing this!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108775

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


[PATCH] D108695: [analyzer][NFCI] Allow clients of NoStateChangeFuncVisitor to check entire function calls, rather than each ExplodedNode in it

2021-08-26 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added a comment.

In D108695#2967885 , @Szelethus wrote:

> It should! But you have a point, I don't have the code to prove it right 
> away. Maybe if I factored out the symbol part into 
> NoStateChangeToSymbolVisitor, as teased in D105553#2864318 
> , it'd have an easier time to see 
> it. With that said, I don't currently see how the current implementation 
> would be faulty, but even if it is, the patch adds an option, and doesn't the 
> take old one (that NoStoreFuncVisitor still uses) away.

I mean, your implementation of `findModifyingFrames()` mostly boils down to:

  return CallEnterN->getState()->get(X) !=
   CallExitEndN->getState()->get(X);

So if, say, X is a mutex and we're wondering whether it was unlocked in the 
function, but in reality it was unlocked and immediately locked again, then the 
above test would say "not modified" and you can't notice that it was modified 
temporarily without scanning all intermediate nodes. So if your note needs to 
make a distinction between "was not touched" and "was touched but reverted" 
you'll still need to do it the old way. I think this should be documented 
loudly in the comments.




Comment at: clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:369
+static const ExplodedNode *getCallExitEnd(const ExplodedNode *N) {
+  while (N && !N->getLocationAs())
+N = N->getFirstSucc();

Wait, no, I don't think this test is sufficient. You may run into a 
`CallExitEnd` of a nested stack frame before you reach the `CallExitEnd` of the 
stack frame in question:
```
-> CallEnter foo()   --->
  -> CallEnter bar()|
  <- CallExitEnd bar()  <--- ???
<- CallExitEnd foo()
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108695

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


[PATCH] D107078: [analyzer] Catch leaking stack addresses via stack variables

2021-08-26 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ accepted this revision.
NoQ added a comment.

Thanks, all clear now!




Comment at: clang/lib/StaticAnalyzer/Checkers/StackAddrEscapeChecker.cpp:325-326
+  if (ReferrerMemSpace && ReferredMemSpace) {
+if (ReferredFrame == PoppedFrame &&
+ReferrerFrame->isParentOf(PoppedFrame)) {
+  V.emplace_back(Referrer, Referred);

steakhal wrote:
> NoQ wrote:
> > You probably meant `||`?
> No, I think `&&` is justified here. We have to make sure that the popped 
> frame is the one that was referred to by some other frame, below that frame.
> 
> {F18569514}
Uh-oh, I misunderstood the whole thing. Looks correct indeed!


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

https://reviews.llvm.org/D107078

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


[PATCH] D105167: [analyzer] Fix HTML report deduplication.

2021-08-26 Thread Artem Dergachev via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG73093599287c: [analyzer] Fix scan-build report 
deduplication. (authored by dergachev.a).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105167

Files:
  clang/include/clang/Analysis/PathDiagnostic.h
  clang/include/clang/StaticAnalyzer/Core/AnalyzerOptions.def
  clang/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
  clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
  clang/test/Analysis/analyzer-config.c
  clang/test/Analysis/scan-build/Inputs/deduplication/1.c
  clang/test/Analysis/scan-build/Inputs/deduplication/2.c
  clang/test/Analysis/scan-build/Inputs/deduplication/header.h
  clang/test/Analysis/scan-build/deduplication.test
  clang/test/Analysis/scan-build/rebuild_index/rebuild_index.test
  clang/test/Analysis/scan-build/rebuild_index/report-3.html
  clang/test/Analysis/scan-build/rebuild_index/subdirectory/report-3.html
  clang/test/Analysis/scan-build/rebuild_index/subdirectory/report-4.html
  clang/tools/scan-build/bin/scan-build

Index: clang/tools/scan-build/bin/scan-build
===
--- clang/tools/scan-build/bin/scan-build
+++ clang/tools/scan-build/bin/scan-build
@@ -14,7 +14,6 @@
 use strict;
 use warnings;
 use FindBin qw($RealBin);
-use Digest::MD5;
 use File::Basename;
 use File::Find;
 use File::Copy qw(copy);
@@ -268,27 +267,6 @@
   $ENV{'CCC_ANALYZER_HTML'} = $Dir;
 }
 
-####
-# ComputeDigest - Compute a digest of the specified file.
-####
-
-sub ComputeDigest {
-  my $FName = shift;
-  DieDiag("Cannot read $FName to compute Digest.\n") if (! -r $FName);
-
-  # Use Digest::MD5.  We don't have to be cryptographically secure.  We're
-  # just looking for duplicate files that come from a non-malicious source.
-  # We use Digest::MD5 because it is a standard Perl module that should
-  # come bundled on most systems.
-  open(FILE, $FName) or DieDiag("Cannot open $FName when computing Digest.\n");
-  binmode FILE;
-  my $Result = Digest::MD5->new->addfile(*FILE)->hexdigest;
-  close(FILE);
-
-  # Return the digest.
-  return $Result;
-}
-
 ####
 #  UpdatePrefix - Compute the common prefix of files.
 ####
@@ -374,8 +352,6 @@
 # Sometimes a source file is scanned more than once, and thus produces
 # multiple error reports.  We use a cache to solve this problem.
 
-my %AlreadyScanned;
-
 sub ScanFile {
 
   my $Index = shift;
@@ -383,19 +359,6 @@
   my $FName = shift;
   my $Stats = shift;
 
-  # Compute a digest for the report file.  Determine if we have already
-  # scanned a file that looks just like it.
-
-  my $digest = ComputeDigest("$Dir/$FName");
-
-  if (defined $AlreadyScanned{$digest}) {
-# Redundant file.  Remove it.
-unlink("$Dir/$FName");
-return;
-  }
-
-  $AlreadyScanned{$digest} = 1;
-
   # At this point the report file is not world readable.  Make it happen.
   chmod(0644, "$Dir/$FName");
 
Index: clang/test/Analysis/scan-build/rebuild_index/subdirectory/report-4.html
===
--- clang/test/Analysis/scan-build/rebuild_index/subdirectory/report-4.html
+++ /dev/null
@@ -1,8 +0,0 @@
-
-
-
-
-
-
-
-
Index: clang/test/Analysis/scan-build/rebuild_index/subdirectory/report-3.html
===
--- /dev/null
+++ clang/test/Analysis/scan-build/rebuild_index/subdirectory/report-3.html
@@ -0,0 +1,8 @@
+
+
+
+
+
+
+
+
Index: clang/test/Analysis/scan-build/rebuild_index/report-3.html
===
--- clang/test/Analysis/scan-build/rebuild_index/report-3.html
+++ /dev/null
@@ -1,8 +0,0 @@
-
-
-
-
-
-
-
-
Index: clang/test/Analysis/scan-build/rebuild_index/rebuild_index.test
===
--- clang/test/Analysis/scan-build/rebuild_index/rebuild_index.test
+++ clang/test/Analysis/scan-build/rebuild_index/rebuild_index.test
@@ -4,9 +4,8 @@
 RUN: rm -rf %t.output_dir && mkdir %t.output_dir
 RUN: cp %S/report-1.html %t.output_dir
 RUN: cp %S/report-2.html %t.output_dir
-RUN: cp %S/report-3.html %t.output_dir
 RUN: mkdir %t.output_dir/subdirectory
-RUN: cp %S/subdirectory/report-4.html %t.output_dir/subdirectory
+RUN: cp %S/subdirectory/report-3.html %t.output_dir/subdirectory
 
 RUN: %scan-build --generate-index-only %t.output_dir
 
@@ -15,16 +14,13 @@
 CHECK-FILES:  index.html
 CHECK-FILES-NEXT: report-1.html
 CHECK-FILES-NEXT: 

[clang] 7309359 - [analyzer] Fix scan-build report deduplication.

2021-08-26 Thread Artem Dergachev via cfe-commits

Author: Artem Dergachev
Date: 2021-08-26T13:34:29-07:00
New Revision: 73093599287cc6d546ac46652ee781789d7de61f

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

LOG: [analyzer] Fix scan-build report deduplication.

The previous behavior was to deduplicate reports based on md5 of the
html file. This algorithm might have worked originally but right now
HTML reports contain information rich enough to make them virtually
always distinct which breaks deduplication entirely.

The new strategy is to (finally) take advantage of IssueHash - the
stable report identifier provided by clang that is the same if and only if
the reports are duplicates of each other.

Additionally, scan-build no longer performs deduplication on its own.
Instead, the report file name is now based on the issue hash,
and clang instances will silently refuse to produce a new html file
when a duplicate already exists. This eliminates the problem entirely.

The '-analyzer-config stable-report-filename' option is deprecated
because report filenames are no longer unstable. A new option is
introduced, '-analyzer-config verbose-report-filename', to produce
verbose file names that look similar to the old "stable" file names.
The old option acts as an alias to the new option.

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

Added: 
clang/test/Analysis/scan-build/Inputs/deduplication/1.c
clang/test/Analysis/scan-build/Inputs/deduplication/2.c
clang/test/Analysis/scan-build/Inputs/deduplication/header.h
clang/test/Analysis/scan-build/deduplication.test
clang/test/Analysis/scan-build/rebuild_index/subdirectory/report-3.html

Modified: 
clang/include/clang/Analysis/PathDiagnostic.h
clang/include/clang/StaticAnalyzer/Core/AnalyzerOptions.def
clang/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
clang/test/Analysis/analyzer-config.c
clang/test/Analysis/scan-build/rebuild_index/rebuild_index.test
clang/tools/scan-build/bin/scan-build

Removed: 
clang/test/Analysis/scan-build/rebuild_index/report-3.html
clang/test/Analysis/scan-build/rebuild_index/subdirectory/report-4.html



diff  --git a/clang/include/clang/Analysis/PathDiagnostic.h 
b/clang/include/clang/Analysis/PathDiagnostic.h
index 04bef1fa5334d..14860c1168e21 100644
--- a/clang/include/clang/Analysis/PathDiagnostic.h
+++ b/clang/include/clang/Analysis/PathDiagnostic.h
@@ -75,14 +75,8 @@ struct PathDiagnosticConsumerOptions {
   bool ShouldSerializeStats = false;
 
   /// If the consumer intends to produce multiple output files, should it
-  /// use randomly generated file names for these files (with the tiny risk of
-  /// having random collisions) or deterministic human-readable file names
-  /// (with a larger risk of deterministic collisions or invalid characters
-  /// in the file name). We should not really give this choice to the users
-  /// because deterministic mode is always superior when done right, but
-  /// for some consumers this mode is experimental and needs to be
-  /// off by default.
-  bool ShouldWriteStableReportFilename = false;
+  /// use a pseudo-random file name name or a human-readable file name.
+  bool ShouldWriteVerboseReportFilename = false;
 
   /// Whether the consumer should treat consumed diagnostics as hard errors.
   /// Useful for breaking your build when issues are found.

diff  --git a/clang/include/clang/StaticAnalyzer/Core/AnalyzerOptions.def 
b/clang/include/clang/StaticAnalyzer/Core/AnalyzerOptions.def
index f0359d2dbb3c2..e97e0a6892a93 100644
--- a/clang/include/clang/StaticAnalyzer/Core/AnalyzerOptions.def
+++ b/clang/include/clang/StaticAnalyzer/Core/AnalyzerOptions.def
@@ -190,7 +190,13 @@ ANALYZER_OPTION(bool, ShouldReportIssuesInMainSourceFile,
 false)
 
 ANALYZER_OPTION(bool, ShouldWriteStableReportFilename, 
"stable-report-filename",
-"Whether or not the report filename should be random or not.",
+"Deprecated: report filenames are now always stable. "
+"See also 'verbose-report-filename'.",
+false)
+
+ANALYZER_OPTION(bool, ShouldWriteVerboseReportFilename, 
"verbose-report-filename",
+"Whether or not the report filename should contain extra "
+"information about the issue.",
 false)
 
 ANALYZER_OPTION(

diff  --git a/clang/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h 
b/clang/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
index ccf35e0a81eca..7514eee7244f8 100644
--- a/clang/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
+++ b/clang/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
@@ -395,7 +395,11 @@ class AnalyzerOptions : public 
RefCountedBase {
 return 

[PATCH] D108765: [docs] Fix documentation of clang-format BasedOnStyle type

2021-08-26 Thread Ludovic Jozeau via Phabricator via cfe-commits
FederAndInk added a comment.

What about: `unsigned`? And enum or struct types such as 
`BracketAlignmentStyle`, `ArrayInitializerAlignmentStyle`, ...?  Should we add 
something like: `Enum BracketAlignmentStyle` and `Dictionnary BraceWrapping`?

The complete list:

  53 bool  -> Boolean
  18 unsigned  -> ?
  9 std::vector   -> List of Strings
  5 std::string-> String
  4 AlignConsecutiveStyle  -> ?
  2 int-> Integer
  1 UseTabStyle-> ?
  1 TrailingCommaStyle -> ?
  1 string -> String
  1 std::vector   -> ?
  1 std::vector   -> ?...
  1 SpacesInLineComment
  1 SpacesInAnglesStyle
  1 SpaceBeforeParensOptions
  1 SpaceAroundPointerQualifiersStyle
  1 SortJavaStaticImportOptions
  1 SortIncludesOptions
  1 ShortLambdaStyle
  1 ShortIfStyle
  1 ShortFunctionStyle
  1 ShortBlockStyle
  1 ReturnTypeBreakingStyle
  1 ReferenceAlignmentStyle
  1 PPDirectiveIndentStyle
  1 PointerAlignmentStyle
  1 OperandAlignmentStyle
  1 NamespaceIndentationKind
  1 LanguageStandard
  1 LanguageKind
  1 LambdaBodyIndentationKind
  1 JavaScriptQuoteStyle
  1 IndentExternBlockStyle
  1 IncludeBlocksStyle
  1 EscapedNewlineAlignmentStyle
  1 EmptyLineBeforeAccessModifierStyle
  1 EmptyLineAfterAccessModifierStyle
  1 DefinitionReturnTypeBreakingStyle
  1 BreakTemplateDeclarationsStyle
  1 BreakInheritanceListStyle
  1 BreakConstructorInitializersStyle
  1 BracketAlignmentStyle
  1 BraceWrappingFlags
  1 BraceBreakingStyle
  1 BitFieldColonSpacingStyle
  1 BinPackStyle
  1 BinaryOperatorStyle
  1 ArrayInitializerAlignmentStyle


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108765

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


[PATCH] D108377: [asan] Implemented flag to emit intrinsics to optimize ASan callbacks.

2021-08-26 Thread Kirill Stoimenov via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGa3f413962627: [asan] Implemented flag to emit intrinsics to 
optimize ASan callbacks. (authored by kstoimenov).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108377

Files:
  llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
  llvm/test/Instrumentation/AddressSanitizer/asan-optimize-callbacks.ll

Index: llvm/test/Instrumentation/AddressSanitizer/asan-optimize-callbacks.ll
===
--- /dev/null
+++ llvm/test/Instrumentation/AddressSanitizer/asan-optimize-callbacks.ll
@@ -0,0 +1,86 @@
+; RUN: opt < %s -asan -enable-new-pm=0 -asan-instrumentation-with-call-threshold=0 \
+; RUN:   -asan-optimize-callbacks -S | FileCheck %s --check-prefixes=LOAD,STORE
+; RUN: opt < %s -asan -enable-new-pm=0 -asan-instrumentation-with-call-threshold=0 \
+; RUN:   -asan-optimize-callbacks --asan-kernel -S | \
+; RUN:   FileCheck %s --check-prefixes=LOAD-KERNEL,STORE-KERNEL
+
+target triple = "x86_64-unknown-linux-gnu"
+
+define void @load(i8* %p1, i16* %p2, i32* %p4, i64* %p8, i128* %p16)
+sanitize_address {
+  %n1 = load i8, i8* %p1, align 1
+  %n2 = load i16, i16* %p2, align 2
+  %n4 = load i32, i32* %p4, align 4
+  %n8 = load i64, i64* %p8, align 8
+  %n16 = load i128, i128* %p16, align 16
+; LOAD:  call void @llvm.asan.check.memaccess(i8* %p1, i32 0)
+; LOAD-NEXT: %n1 = load i8, i8* %p1, align 1
+; LOAD-NEXT: %1 = bitcast i16* %p2 to i8*
+; LOAD-NEXT: call void @llvm.asan.check.memaccess(i8* %1, i32 2)
+; LOAD-NEXT: %n2 = load i16, i16* %p2, align 2
+; LOAD-NEXT: %2 = bitcast i32* %p4 to i8*
+; LOAD-NEXT: call void @llvm.asan.check.memaccess(i8* %2, i32 4)
+; LOAD-NEXT: %n4 = load i32, i32* %p4, align 4
+; LOAD-NEXT: %3 = bitcast i64* %p8 to i8*
+; LOAD-NEXT: call void @llvm.asan.check.memaccess(i8* %3, i32 6)
+; LOAD-NEXT: %n8 = load i64, i64* %p8, align 8
+; LOAD-NEXT: %4 = bitcast i128* %p16 to i8*
+; LOAD-NEXT: call void @llvm.asan.check.memaccess(i8* %4, i32 8)
+; LOAD-NEXT: %n16 = load i128, i128* %p16, align 16
+
+; LOAD-KERNEL:  call void @llvm.asan.check.memaccess(i8* %p1, i32 1)
+; LOAD-KERNEL-NEXT: %n1 = load i8, i8* %p1, align 1
+; LOAD-KERNEL-NEXT: %1 = bitcast i16* %p2 to i8*
+; LOAD-KERNEL-NEXT: call void @llvm.asan.check.memaccess(i8* %1, i32 3)
+; LOAD-KERNEL-NEXT: %n2 = load i16, i16* %p2, align 2
+; LOAD-KERNEL-NEXT: %2 = bitcast i32* %p4 to i8*
+; LOAD-KERNEL-NEXT: call void @llvm.asan.check.memaccess(i8* %2, i32 5)
+; LOAD-KERNEL-NEXT: %n4 = load i32, i32* %p4, align 4
+; LOAD-KERNEL-NEXT: %3 = bitcast i64* %p8 to i8*
+; LOAD-KERNEL-NEXT: call void @llvm.asan.check.memaccess(i8* %3, i32 7)
+; LOAD-KERNEL-NEXT: %n8 = load i64, i64* %p8, align 8
+; LOAD-KERNEL-NEXT: %4 = bitcast i128* %p16 to i8*
+; LOAD-KERNEL-NEXT: call void @llvm.asan.check.memaccess(i8* %4, i32 9)
+; LOAD-KERNEL-NEXT: %n16 = load i128, i128* %p16, align 16
+  ret void
+}
+
+define void @store(i8* %p1, i16* %p2, i32* %p4, i64* %p8, i128* %p16)
+sanitize_address {
+  store i8 0, i8* %p1, align 1
+  store i16 0, i16* %p2, align 2
+  store i32 0, i32* %p4, align 4
+  store i64 0, i64* %p8, align 8
+  store i128 0, i128* %p16, align 16
+; STORE:  call void @llvm.asan.check.memaccess(i8* %p1, i32 32)
+; STORE-NEXT: store i8 0, i8* %p1, align 1
+; STORE-NEXT: %1 = bitcast i16* %p2 to i8*
+; STORE-NEXT: call void @llvm.asan.check.memaccess(i8* %1, i32 34)
+; STORE-NEXT: store i16 0, i16* %p2, align 2
+; STORE-NEXT: %2 = bitcast i32* %p4 to i8*
+; STORE-NEXT: call void @llvm.asan.check.memaccess(i8* %2, i32 36)
+; STORE-NEXT: store i32 0, i32* %p4, align 4
+; STORE-NEXT: %3 = bitcast i64* %p8 to i8*
+; STORE-NEXT: call void @llvm.asan.check.memaccess(i8* %3, i32 38)
+; STORE-NEXT: store i64 0, i64* %p8, align 8
+; STORE-NEXT: %4 = bitcast i128* %p16 to i8*
+; STORE-NEXT: call void @llvm.asan.check.memaccess(i8* %4, i32 40)
+; STORE-NEXT: store i128 0, i128* %p16, align 16
+
+; STORE-KERNEL:  call void @llvm.asan.check.memaccess(i8* %p1, i32 33)
+; STORE-KERNEL-NEXT: store i8 0, i8* %p1, align 1
+; STORE-KERNEL-NEXT: %1 = bitcast i16* %p2 to i8*
+; STORE-KERNEL-NEXT: call void @llvm.asan.check.memaccess(i8* %1, i32 35)
+; STORE-KERNEL-NEXT: store i16 0, i16* %p2, align 2
+; STORE-KERNEL-NEXT: %2 = bitcast i32* %p4 to i8*
+; STORE-KERNEL-NEXT: call void @llvm.asan.check.memaccess(i8* %2, i32 37)
+; STORE-KERNEL-NEXT: store i32 0, i32* %p4, align 4
+; STORE-KERNEL-NEXT: %3 = bitcast i64* %p8 to i8*
+; STORE-KERNEL-NEXT: call void @llvm.asan.check.memaccess(i8* %3, i32 39)
+; STORE-KERNEL-NEXT: store i64 0, i64* %p8, align 8
+; STORE-KERNEL-NEXT: %4 = bitcast i128* %p16 to i8*
+; STORE-KERNEL-NEXT: call void @llvm.asan.check.memaccess(i8* %4, i32 41)
+; STORE-KERNEL-NEXT: store i128 0, i128* %p16, align 16
+; STORE-KERNEL-NEXT: ret void
+  ret void
+}
Index: 

[PATCH] D104858: [OpenCL][ARM] Fix ICE when compiling a kernel

2021-08-26 Thread Stuart Brady via Phabricator via cfe-commits
stuart added a comment.

> Unfortunately I cannot look at this in detail right now, but I'll reply 
> quickly for a heads up: The problem was not how to detect kernels, but the 
> ABI/CC mismatch to the
> clSetKerneArg() with (user facing) arguments that get split to multiple args 
> or vice versa. E.g. x86 ABI had a CC where 2xfloat gets to 1xdouble in the 
> generated function
> finger print, thus there was no 1:1 match of the kernel arguments to the 
> OpenCL-facing ones (making clSetKernelArg calls difficult to implement 
> robustly).

Could you not just use libffi?


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

https://reviews.llvm.org/D104858

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


[PATCH] D108774: [OpenMP][FIX] Allow declare variant to work with reference types

2021-08-26 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield added a comment.

That is a surprising root cause. It turns out std::cexp does in fact take the 
complex argument by const reference. The C versions take it by value. Shall we 
guard this with if (openmp) or similar to avoid it changing semantics for other 
languages?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108774

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


[PATCH] D108377: [asan] Implemented flag to emit intrinsics to optimize ASan callbacks.

2021-08-26 Thread Vitaly Buka via Phabricator via cfe-commits
vitalybuka accepted this revision.
vitalybuka added inline comments.
This revision is now accepted and ready to land.



Comment at: 
llvm/test/Instrumentation/AddressSanitizer/asan-optimize-callbacks.ll:6
+; RUN:   FileCheck %s --check-prefixes=LOAD-KERNEL,STORE-KERNEL
+
+target triple = "x86_64-unknown-linux-gnu"

Can you please include negative cases as well?

; RUN: opt < %s -asan -enable-new-pm=0 
-asan-instrumentation-with-call-threshold=0 -asan-optimize-callbacks=0 -S | 
FileCheck %s --implicit-check-not llvm.asan.check.memaccess
; RUN: opt < %s -asan -enable-new-pm=0 
-asan-instrumentation-with-call-threshold=0 -asan-optimize-callbacks=0 
--asan-kernel -S | FileCheck %s --implicit-check-not llvm.asan.check.memaccess



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108377

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


[PATCH] D108774: [OpenMP][FIX] Allow declare variant to work with reference types

2021-08-26 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added inline comments.



Comment at: clang/lib/AST/ASTContext.cpp:9691
   // the expression is a function call (possibly inside parentheses).
+  if (LHS->getAs() && RHS->getAs())
+return mergeTypes(LHS->getAs()->getPointeeType(),

Does it matter if it is an LValueReferenceType or RValueReferenceType? What if 
one type is `&` ref kind and another is `&&`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108774

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


[PATCH] D108482: [Clang] Fix instantiation of OpaqueValueExprs (Bug #45964)

2021-08-26 Thread Jason Rice via Phabricator via cfe-commits
ricejasonf updated this revision to Diff 368962.
ricejasonf added a comment.

I moved the test to CodeGenCXX and actually test output with FileCheck. I used 
the code from a non-template function as the expected output. Some minor 
formatting changes are also addressed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108482

Files:
  clang/lib/Sema/SemaInit.cpp
  clang/lib/Sema/TreeTransform.h
  clang/test/CodeGenCXX/pr45964-decomp-transform.cpp


Index: clang/test/CodeGenCXX/pr45964-decomp-transform.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/pr45964-decomp-transform.cpp
@@ -0,0 +1,27 @@
+// RUN: %clang_cc1 -std=c++1z -triple x86_64-linux-gnu -emit-llvm -o - %s | 
FileCheck %s
+
+int a[1];
+// CHECK: @a = global [1 x i32] zeroinitializer
+template 
+void test_transform() {
+  auto [b] = a;
+}
+void (*d)(){test_transform<0>};
+// CHECK-LABEL: define {{.*}} @_Z14test_transformILi0EEvv
+// CHECK:   [[ENTRY:.*]]:
+// CHECK-NEXT:  [[ARR:%.*]] = alloca [1 x i32]
+// CHECK-NEXT:  [[BEGIN:%.*]] = getelementptr inbounds [1 x i32], [1 x i32]* 
[[ARR]], i64 0, i64 0
+// CHECK-NEXT:  br label %[[BODY:.*]]
+// CHECK-EMPTY:
+// CHECK-NEXT:  [[BODY]]:
+// CHECK-NEXT:  [[CUR:%.*]] = phi i64 [ 0, %[[ENTRY]] ], [ [[NEXT:%.*]], 
%[[BODY]] ]
+// CHECK-NEXT:  [[DEST:%.*]] = getelementptr inbounds i32, i32* [[BEGIN]], i64 
[[CUR]]
+// CHECK-NEXT:  [[SRC:%.*]] = getelementptr inbounds [1 x i32], [1 x i32]* @a, 
i64 0, i64 [[CUR]]
+// CHECK-NEXT:  [[X:%.*]] = load i32, i32* [[SRC]]
+// CHECK-NEXT:  store i32 [[X]], i32* [[DEST]]
+// CHECK-NEXT:  [[NEXT]] = add nuw i64 [[CUR]], 1
+// CHECK-NEXT:  [[EQ:%.*]] = icmp eq i64 [[NEXT]], 1
+// CHECK-NEXT:  br i1 [[EQ]], label %[[FIN:.*]], label %[[BODY]]
+// CHECK-EMPTY:
+// CHECK-NEXT:  [[FIN]]:
+// CHECK-NEXT:  ret void
Index: clang/lib/Sema/TreeTransform.h
===
--- clang/lib/Sema/TreeTransform.h
+++ clang/lib/Sema/TreeTransform.h
@@ -10511,7 +10511,18 @@
 TreeTransform::TransformOpaqueValueExpr(OpaqueValueExpr *E) {
   assert((!E->getSourceExpr() || 
getDerived().AlreadyTransformed(E->getType())) &&
  "opaque value expression requires transformation");
-  return E;
+
+  // Note that SourceExpr can be nullptr.
+  ExprResult SourceExpr = TransformExpr(E->getSourceExpr());
+  if (SourceExpr.isInvalid())
+return ExprError();
+  if (SourceExpr.get() == E->getSourceExpr() && !getDerived().AlwaysRebuild())
+return E;
+
+  OpaqueValueExpr *New = new (SemaRef.Context)
+  OpaqueValueExpr(E->getExprLoc(), E->getType(), E->getValueKind(),
+  E->getObjectKind(), SourceExpr.get());
+  return New;
 }
 
 template
Index: clang/lib/Sema/SemaInit.cpp
===
--- clang/lib/Sema/SemaInit.cpp
+++ clang/lib/Sema/SemaInit.cpp
@@ -8643,9 +8643,13 @@
 
 case SK_ArrayLoopIndex: {
   Expr *Cur = CurInit.get();
-  Expr *BaseExpr = new (S.Context)
-  OpaqueValueExpr(Cur->getExprLoc(), Cur->getType(),
-  Cur->getValueKind(), Cur->getObjectKind(), Cur);
+  // Prevent nested OpaqueValueExprs.
+  Expr *BaseExpr = dyn_cast(Cur);
+  if (!BaseExpr) {
+BaseExpr = new (S.Context)
+OpaqueValueExpr(Cur->getExprLoc(), Cur->getType(),
+Cur->getValueKind(), Cur->getObjectKind(), Cur);
+  }
   Expr *IndexExpr =
   new (S.Context) ArrayInitIndexExpr(S.Context.getSizeType());
   CurInit = S.CreateBuiltinArraySubscriptExpr(


Index: clang/test/CodeGenCXX/pr45964-decomp-transform.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/pr45964-decomp-transform.cpp
@@ -0,0 +1,27 @@
+// RUN: %clang_cc1 -std=c++1z -triple x86_64-linux-gnu -emit-llvm -o - %s | FileCheck %s
+
+int a[1];
+// CHECK: @a = global [1 x i32] zeroinitializer
+template 
+void test_transform() {
+  auto [b] = a;
+}
+void (*d)(){test_transform<0>};
+// CHECK-LABEL: define {{.*}} @_Z14test_transformILi0EEvv
+// CHECK:   [[ENTRY:.*]]:
+// CHECK-NEXT:  [[ARR:%.*]] = alloca [1 x i32]
+// CHECK-NEXT:  [[BEGIN:%.*]] = getelementptr inbounds [1 x i32], [1 x i32]* [[ARR]], i64 0, i64 0
+// CHECK-NEXT:  br label %[[BODY:.*]]
+// CHECK-EMPTY:
+// CHECK-NEXT:  [[BODY]]:
+// CHECK-NEXT:  [[CUR:%.*]] = phi i64 [ 0, %[[ENTRY]] ], [ [[NEXT:%.*]], %[[BODY]] ]
+// CHECK-NEXT:  [[DEST:%.*]] = getelementptr inbounds i32, i32* [[BEGIN]], i64 [[CUR]]
+// CHECK-NEXT:  [[SRC:%.*]] = getelementptr inbounds [1 x i32], [1 x i32]* @a, i64 0, i64 [[CUR]]
+// CHECK-NEXT:  [[X:%.*]] = load i32, i32* [[SRC]]
+// CHECK-NEXT:  store i32 [[X]], i32* [[DEST]]
+// CHECK-NEXT:  [[NEXT]] = add nuw i64 [[CUR]], 1
+// CHECK-NEXT:  [[EQ:%.*]] = icmp eq i64 [[NEXT]], 1
+// CHECK-NEXT:  br i1 [[EQ]], label 

[PATCH] D108377: [asan] Implemented flag to emit intrinsics to optimize ASan callbacks.

2021-08-26 Thread Kirill Stoimenov via Phabricator via cfe-commits
kstoimenov updated this revision to Diff 368959.
kstoimenov added a comment.

Fixed the test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108377

Files:
  llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
  llvm/test/Instrumentation/AddressSanitizer/asan-optimize-callbacks.ll

Index: llvm/test/Instrumentation/AddressSanitizer/asan-optimize-callbacks.ll
===
--- /dev/null
+++ llvm/test/Instrumentation/AddressSanitizer/asan-optimize-callbacks.ll
@@ -0,0 +1,86 @@
+; RUN: opt < %s -asan -enable-new-pm=0 -asan-instrumentation-with-call-threshold=0 \
+; RUN:   -asan-optimize-callbacks -S | FileCheck %s --check-prefixes=LOAD,STORE
+; RUN: opt < %s -asan -enable-new-pm=0 -asan-instrumentation-with-call-threshold=0 \
+; RUN:   -asan-optimize-callbacks --asan-kernel -S | \
+; RUN:   FileCheck %s --check-prefixes=LOAD-KERNEL,STORE-KERNEL
+
+target triple = "x86_64-unknown-linux-gnu"
+
+define void @load(i8* %p1, i16* %p2, i32* %p4, i64* %p8, i128* %p16)
+sanitize_address {
+  %n1 = load i8, i8* %p1, align 1
+  %n2 = load i16, i16* %p2, align 2
+  %n4 = load i32, i32* %p4, align 4
+  %n8 = load i64, i64* %p8, align 8
+  %n16 = load i128, i128* %p16, align 16
+; LOAD:  call void @llvm.asan.check.memaccess(i8* %p1, i32 0)
+; LOAD-NEXT: %n1 = load i8, i8* %p1, align 1
+; LOAD-NEXT: %1 = bitcast i16* %p2 to i8*
+; LOAD-NEXT: call void @llvm.asan.check.memaccess(i8* %1, i32 2)
+; LOAD-NEXT: %n2 = load i16, i16* %p2, align 2
+; LOAD-NEXT: %2 = bitcast i32* %p4 to i8*
+; LOAD-NEXT: call void @llvm.asan.check.memaccess(i8* %2, i32 4)
+; LOAD-NEXT: %n4 = load i32, i32* %p4, align 4
+; LOAD-NEXT: %3 = bitcast i64* %p8 to i8*
+; LOAD-NEXT: call void @llvm.asan.check.memaccess(i8* %3, i32 6)
+; LOAD-NEXT: %n8 = load i64, i64* %p8, align 8
+; LOAD-NEXT: %4 = bitcast i128* %p16 to i8*
+; LOAD-NEXT: call void @llvm.asan.check.memaccess(i8* %4, i32 8)
+; LOAD-NEXT: %n16 = load i128, i128* %p16, align 16
+
+; LOAD-KERNEL:  call void @llvm.asan.check.memaccess(i8* %p1, i32 1)
+; LOAD-KERNEL-NEXT: %n1 = load i8, i8* %p1, align 1
+; LOAD-KERNEL-NEXT: %1 = bitcast i16* %p2 to i8*
+; LOAD-KERNEL-NEXT: call void @llvm.asan.check.memaccess(i8* %1, i32 3)
+; LOAD-KERNEL-NEXT: %n2 = load i16, i16* %p2, align 2
+; LOAD-KERNEL-NEXT: %2 = bitcast i32* %p4 to i8*
+; LOAD-KERNEL-NEXT: call void @llvm.asan.check.memaccess(i8* %2, i32 5)
+; LOAD-KERNEL-NEXT: %n4 = load i32, i32* %p4, align 4
+; LOAD-KERNEL-NEXT: %3 = bitcast i64* %p8 to i8*
+; LOAD-KERNEL-NEXT: call void @llvm.asan.check.memaccess(i8* %3, i32 7)
+; LOAD-KERNEL-NEXT: %n8 = load i64, i64* %p8, align 8
+; LOAD-KERNEL-NEXT: %4 = bitcast i128* %p16 to i8*
+; LOAD-KERNEL-NEXT: call void @llvm.asan.check.memaccess(i8* %4, i32 9)
+; LOAD-KERNEL-NEXT: %n16 = load i128, i128* %p16, align 16
+  ret void
+}
+
+define void @store(i8* %p1, i16* %p2, i32* %p4, i64* %p8, i128* %p16)
+sanitize_address {
+  store i8 0, i8* %p1, align 1
+  store i16 0, i16* %p2, align 2
+  store i32 0, i32* %p4, align 4
+  store i64 0, i64* %p8, align 8
+  store i128 0, i128* %p16, align 16
+; STORE:  call void @llvm.asan.check.memaccess(i8* %p1, i32 32)
+; STORE-NEXT: store i8 0, i8* %p1, align 1
+; STORE-NEXT: %1 = bitcast i16* %p2 to i8*
+; STORE-NEXT: call void @llvm.asan.check.memaccess(i8* %1, i32 34)
+; STORE-NEXT: store i16 0, i16* %p2, align 2
+; STORE-NEXT: %2 = bitcast i32* %p4 to i8*
+; STORE-NEXT: call void @llvm.asan.check.memaccess(i8* %2, i32 36)
+; STORE-NEXT: store i32 0, i32* %p4, align 4
+; STORE-NEXT: %3 = bitcast i64* %p8 to i8*
+; STORE-NEXT: call void @llvm.asan.check.memaccess(i8* %3, i32 38)
+; STORE-NEXT: store i64 0, i64* %p8, align 8
+; STORE-NEXT: %4 = bitcast i128* %p16 to i8*
+; STORE-NEXT: call void @llvm.asan.check.memaccess(i8* %4, i32 40)
+; STORE-NEXT: store i128 0, i128* %p16, align 16
+
+; STORE-KERNEL:  call void @llvm.asan.check.memaccess(i8* %p1, i32 33)
+; STORE-KERNEL-NEXT: store i8 0, i8* %p1, align 1
+; STORE-KERNEL-NEXT: %1 = bitcast i16* %p2 to i8*
+; STORE-KERNEL-NEXT: call void @llvm.asan.check.memaccess(i8* %1, i32 35)
+; STORE-KERNEL-NEXT: store i16 0, i16* %p2, align 2
+; STORE-KERNEL-NEXT: %2 = bitcast i32* %p4 to i8*
+; STORE-KERNEL-NEXT: call void @llvm.asan.check.memaccess(i8* %2, i32 37)
+; STORE-KERNEL-NEXT: store i32 0, i32* %p4, align 4
+; STORE-KERNEL-NEXT: %3 = bitcast i64* %p8 to i8*
+; STORE-KERNEL-NEXT: call void @llvm.asan.check.memaccess(i8* %3, i32 39)
+; STORE-KERNEL-NEXT: store i64 0, i64* %p8, align 8
+; STORE-KERNEL-NEXT: %4 = bitcast i128* %p16 to i8*
+; STORE-KERNEL-NEXT: call void @llvm.asan.check.memaccess(i8* %4, i32 41)
+; STORE-KERNEL-NEXT: store i128 0, i128* %p16, align 16
+; STORE-KERNEL-NEXT: ret void
+  ret void
+}
Index: llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
===
--- 

[PATCH] D108479: [Clang] Add __builtin_addressof_nocfi

2021-08-26 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers added inline comments.



Comment at: clang/lib/CodeGen/CGExprConstant.cpp:1890
 
-if (auto FD = dyn_cast(D))
-  return CGM.GetAddrOfFunction(FD);
+if (auto FD = dyn_cast(D)) {
+  auto *C = CGM.GetAddrOfFunction(FD);

fix linter warning



Comment at: clang/lib/CodeGen/CGExprConstant.cpp:1891
+if (auto FD = dyn_cast(D)) {
+  auto *C = CGM.GetAddrOfFunction(FD);
+  if (base.isNoCFIValue())

Don't use `auto` here.
https://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable
It's common when the type is already specified on the RHS of an assignment 
that's using of the casting operators that's already explicitly specialized 
with the type.



Comment at: clang/test/CodeGen/builtin-addressof-nocfi.c:18
+  // CHECK: call void @c(void ()* no_cfi @a)
+  c(__builtin_addressof_nocfi(a));
+  e();

do we ever need the builtin address of a global that's NOT a function?

If so, we should add a test for that. If not, perhaps we don't need to waste 
space in every APValue?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108479

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


[PATCH] D108695: [analyzer][NFCI] Allow clients of NoStateChangeFuncVisitor to check entire function calls, rather than each ExplodedNode in it

2021-08-26 Thread Kristóf Umann via Phabricator via cfe-commits
Szelethus added a comment.

In D108695#2967540 , @NoQ wrote:

> Would this work correctly when the property is changed but then reverted to 
> its original state? This probably can't happen to MallocChecker (what has 
> been freed cannot be unfreed) but it may happen to eg. PthreadLockChecker or 
> to, well, Stores. In such cases it would be incorrect to say "returning 
> without changing the state".

It should! But you have a point, I don't have the code to prove it right away. 
Maybe if I factored out the symbol part into NoStateChangeToSymbolVisitor, as 
teased in D105553#2864318 , it'd have 
an easier time to see it. With that said, I don't currently see how the current 
implementation would be faulty, but even if it is, the patch adds an option, 
and doesn't the take old one (that NoStoreFuncVisitor still uses) away.




Comment at: clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:370
+  while (N && !N->getLocationAs())
+N = N->getFirstSucc();
+  return N;

NoQ wrote:
> This is the right successor because we're in a heavily trimmed exploded 
> graph, right?
Should be, yes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108695

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


[PATCH] D108742: Reclassify form-feed and vertical tab as vertical WS for the purposes of lexing.

2021-08-26 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin updated this revision to Diff 368958.
cor3ntin added a comment.

- Add tests and fix existing tests (again)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108742

Files:
  clang/lib/Basic/CharInfo.cpp
  clang/unittests/Basic/CharInfoTest.cpp
  clang/unittests/Lex/DependencyDirectivesSourceMinimizerTest.cpp
  clang/unittests/Lex/LexerTest.cpp

Index: clang/unittests/Lex/LexerTest.cpp
===
--- clang/unittests/Lex/LexerTest.cpp
+++ clang/unittests/Lex/LexerTest.cpp
@@ -493,10 +493,10 @@
 
   EXPECT_TRUE(hasNewLineEscaped("\\\r"));
   EXPECT_TRUE(hasNewLineEscaped("\\\n"));
+  EXPECT_TRUE(hasNewLineEscaped("\\\v"));
   EXPECT_TRUE(hasNewLineEscaped("\\\r\n"));
   EXPECT_TRUE(hasNewLineEscaped("\\\n\r"));
-  EXPECT_TRUE(hasNewLineEscaped("\\ \t\v\f\r"));
-  EXPECT_TRUE(hasNewLineEscaped("\\ \t\v\f\r\n"));
+  EXPECT_TRUE(hasNewLineEscaped("\\ \t\r\n"));
 
   EXPECT_FALSE(hasNewLineEscaped("\\\r\r"));
   EXPECT_FALSE(hasNewLineEscaped("\\\r\r\n"));
Index: clang/unittests/Lex/DependencyDirectivesSourceMinimizerTest.cpp
===
--- clang/unittests/Lex/DependencyDirectivesSourceMinimizerTest.cpp
+++ clang/unittests/Lex/DependencyDirectivesSourceMinimizerTest.cpp
@@ -162,18 +162,6 @@
   ASSERT_FALSE(minimizeSourceToDependencyDirectives(
   "#define MACRO(\t)\tcon \t tent\t", Out));
   EXPECT_STREQ("#define MACRO() con \t tent\n", Out.data());
-
-  ASSERT_FALSE(minimizeSourceToDependencyDirectives(
-  "#define MACRO(\f)\fcon \f tent\f", Out));
-  EXPECT_STREQ("#define MACRO() con \f tent\n", Out.data());
-
-  ASSERT_FALSE(minimizeSourceToDependencyDirectives(
-  "#define MACRO(\v)\vcon \v tent\v", Out));
-  EXPECT_STREQ("#define MACRO() con \v tent\n", Out.data());
-
-  ASSERT_FALSE(minimizeSourceToDependencyDirectives(
-  "#define MACRO \t\v\f\v\t con\f\t\vtent\v\f \v", Out));
-  EXPECT_STREQ("#define MACRO con\f\t\vtent\n", Out.data());
 }
 
 TEST(MinimizeSourceToDependencyDirectivesTest, DefineMultilineArgs) {
@@ -194,6 +182,29 @@
   EXPECT_STREQ("#define MACRO(a,b) call((a), (b))\n", Out.data());
 }
 
+TEST(MinimizeSourceToDependencyDirectivesTest,
+ DefineMultilineArgsVerticalWhiteSpaces) {
+  SmallVector Out;
+
+  ASSERT_FALSE(
+  minimizeSourceToDependencyDirectives("#define MACRO(a\\\f"
+   "  )",
+   Out));
+  EXPECT_STREQ("#define MACRO(a)\n", Out.data());
+
+  ASSERT_FALSE(
+  minimizeSourceToDependencyDirectives("#define MACRO(a\\\v"
+   "  )",
+   Out));
+  EXPECT_STREQ("#define MACRO(a)\n", Out.data());
+
+  ASSERT_FALSE(minimizeSourceToDependencyDirectives(
+  "#define MACRO(a\\\f\\\v\\\v\\\f"
+  "  )",
+  Out));
+  EXPECT_STREQ("#define MACRO(a)\n", Out.data());
+}
+
 TEST(MinimizeSourceToDependencyDirectivesTest,
  DefineMultilineArgsCarriageReturn) {
   SmallVector Out;
Index: clang/unittests/Basic/CharInfoTest.cpp
===
--- clang/unittests/Basic/CharInfoTest.cpp
+++ clang/unittests/Basic/CharInfoTest.cpp
@@ -17,8 +17,8 @@
   using namespace charinfo;
   EXPECT_EQ((unsigned)CHAR_SPACE,   InfoTable[(unsigned)' ']);
   EXPECT_EQ((unsigned)CHAR_HORZ_WS, InfoTable[(unsigned)'\t']);
-  EXPECT_EQ((unsigned)CHAR_HORZ_WS, InfoTable[(unsigned)'\f']); // ??
-  EXPECT_EQ((unsigned)CHAR_HORZ_WS, InfoTable[(unsigned)'\v']); // ??
+  EXPECT_EQ((unsigned)CHAR_VERT_WS, InfoTable[(unsigned)'\f']);
+  EXPECT_EQ((unsigned)CHAR_VERT_WS, InfoTable[(unsigned)'\v']);
   EXPECT_EQ((unsigned)CHAR_VERT_WS, InfoTable[(unsigned)'\n']);
   EXPECT_EQ((unsigned)CHAR_VERT_WS, InfoTable[(unsigned)'\r']);
   EXPECT_EQ((unsigned)CHAR_UNDER,   InfoTable[(unsigned)'_']);
@@ -101,8 +101,6 @@
 
   EXPECT_TRUE(isHorizontalWhitespace(' '));
   EXPECT_TRUE(isHorizontalWhitespace('\t'));
-  EXPECT_TRUE(isHorizontalWhitespace('\f')); // ??
-  EXPECT_TRUE(isHorizontalWhitespace('\v')); // ??
 
   EXPECT_FALSE(isHorizontalWhitespace('\n'));
   EXPECT_FALSE(isHorizontalWhitespace('\r'));
@@ -123,9 +121,9 @@
 
   EXPECT_FALSE(isVerticalWhitespace(' '));
   EXPECT_FALSE(isVerticalWhitespace('\t'));
-  EXPECT_FALSE(isVerticalWhitespace('\f')); // ??
-  EXPECT_FALSE(isVerticalWhitespace('\v')); // ??
 
+  EXPECT_TRUE(isVerticalWhitespace('\f')); // ??
+  EXPECT_TRUE(isVerticalWhitespace('\v')); // ??
   EXPECT_TRUE(isVerticalWhitespace('\n'));
   EXPECT_TRUE(isVerticalWhitespace('\r'));
 
Index: clang/lib/Basic/CharInfo.cpp
===
--- clang/lib/Basic/CharInfo.cpp
+++ clang/lib/Basic/CharInfo.cpp
@@ -12,6 +12,7 @@
 
 // Statically initialize CharInfo table 

[PATCH] D108765: [docs] Fix documentation of clang-format BasedOnStyle type

2021-08-26 Thread Björn Schäpers via Phabricator via cfe-commits
HazardyKnusperkeks requested changes to this revision.
HazardyKnusperkeks added a comment.

As the one who wrote that:

1. Yes that part is not auto generated, because it is not in the `format.h`.
2. I'm more in favor of removing the `std::` from the documentation.
3. It is for the YAML documentation, then stick with the YAML names: `List of 
Strings` is my proposal.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108765

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


[PATCH] D108752: [clang-format] Group options that pack constructor initializers

2021-08-26 Thread Björn Schäpers via Phabricator via cfe-commits
HazardyKnusperkeks accepted this revision.
HazardyKnusperkeks added inline comments.



Comment at: clang/unittests/Format/FormatTest.cpp:18472
+  FormatStyle::PCIS_Never);
+
   Style.EmptyLineBeforeAccessModifier = FormatStyle::ELBAMS_LogicalBlock;

Should there be a test for the mapping?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108752

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


[PATCH] D108742: Reclassify form-feed and vertical tab as vertical WS for the purposes of lexing.

2021-08-26 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin added inline comments.



Comment at: 
clang/unittests/Lex/DependencyDirectivesSourceMinimizerTest.cpp:170-173
   ASSERT_FALSE(
-  minimizeSourceToDependencyDirectives("#define MACRO(a\\\n"
+  minimizeSourceToDependencyDirectives("#define MACRO(a
\\\n\\\v\\\f"
"  )",
Out));

dexonsmith wrote:
> Please don't modify this assertion to test `\v` and `\f`. Instead add new 
> assertions. I'm not sure if they belong in `DefineMultilineArgs`, or if 
> `DefineSpacing` might be a better spot, or maybe a new test 
> `DefineVerticalWhitespace`?
I think this test is useful, you are right I should add more somewhere else. I 
will also add that new test without removing the old one!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108742

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


[PATCH] D108775: [CMake] Change -DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=off to -DLLVM_ENABLE_NEW_PASS_MANAGER=off

2021-08-26 Thread Arthur Eubanks via Phabricator via cfe-commits
aeubanks accepted this revision.
aeubanks added a comment.
This revision is now accepted and ready to land.

this is good, but IMO it's not clear enough in the description that this is a 
breaking change in terms of CMake flags (use -DLLVM_ENABLE_NEW_PASS_MANAGER 
instead of -DEXPERIMENTAL_NEW_PASS_MANAGER)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108775

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


[PATCH] D108774: [OpenMP][FIX] Allow declare variant to work with reference types

2021-08-26 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert updated this revision to Diff 368943.
jdoerfert added a comment.

Clang format patch


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108774

Files:
  clang/lib/AST/ASTContext.cpp
  clang/test/AST/ast-dump-openmp-begin-declare-variant_reference.cpp

Index: clang/test/AST/ast-dump-openmp-begin-declare-variant_reference.cpp
===
--- /dev/null
+++ clang/test/AST/ast-dump-openmp-begin-declare-variant_reference.cpp
@@ -0,0 +1,148 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fopenmp -verify -ast-dump %s   | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fopenmp -verify -ast-dump %s -x c++| FileCheck %s
+// expected-no-diagnostics
+
+int Good, Bad;
+int _before() {
+  return Bad;
+}
+
+#pragma omp begin declare variant match(implementation = {vendor(score(100) \
+ : llvm)})
+int also_after(void) {
+  return 2;
+}
+int also_after(int &) {
+  return 3;
+}
+int also_after(double &) {
+  return 0;
+}
+#pragma omp end declare variant
+#pragma omp begin declare variant match(implementation = {vendor(score(0) \
+ : llvm)})
+int _before() {
+  return Good;
+}
+#pragma omp end declare variant
+
+int also_after(void) {
+  return 4;
+}
+int also_after(int) {
+  return 5;
+}
+int also_after(double &) {
+  return 6;
+}
+
+int test1() {
+  // Should return 0.
+  double d;
+  return also_after(d);
+}
+
+int test2() {
+  // Should return 0.
+  return _before() == 
+}
+
+int test() {
+  // Should return 0.
+  return test1() + test2();
+}
+
+// CHECK:  |-VarDecl [[ADDR_0:0x[a-z0-9]*]] <{{.*}}, col:5> col:5 used Good 'int'
+// CHECK-NEXT: |-VarDecl [[ADDR_1:0x[a-z0-9]*]]  col:11 used Bad 'int'
+// CHECK-NEXT: |-FunctionDecl [[ADDR_2:0x[a-z0-9]*]]  line:6:6 used also_before 'int &({{.*}})'
+// CHECK-NEXT: | |-CompoundStmt [[ADDR_3:0x[a-z0-9]*]] 
+// CHECK-NEXT: | | `-ReturnStmt [[ADDR_4:0x[a-z0-9]*]] 
+// CHECK-NEXT: | |   `-DeclRefExpr [[ADDR_5:0x[a-z0-9]*]]  'int' {{.*}}Var [[ADDR_1]] 'Bad' 'int'
+// CHECK-NEXT: | `-OMPDeclareVariantAttr [[ADDR_6:0x[a-z0-9]*]] <> Implicit implementation={vendor(score(0): llvm)}
+// CHECK-NEXT: |   `-DeclRefExpr [[ADDR_7:0x[a-z0-9]*]]  'int &({{.*}})' {{.*}}Function [[ADDR_8:0x[a-z0-9]*]] 'also_before[implementation={vendor(llvm)}]' 'int &({{.*}})'
+// CHECK-NEXT: |-FunctionDecl [[ADDR_9:0x[a-z0-9]*]]  col:5 implicit also_after 'int ({{.*}})'
+// CHECK-NEXT: | `-OMPDeclareVariantAttr [[ADDR_10:0x[a-z0-9]*]] <> Implicit implementation={vendor(score(100): llvm)}
+// CHECK-NEXT: |   `-DeclRefExpr [[ADDR_11:0x[a-z0-9]*]]  'int ({{.*}})' {{.*}}Function [[ADDR_12:0x[a-z0-9]*]] 'also_after[implementation={vendor(llvm)}]' 'int ({{.*}})'
+// CHECK-NEXT: |-FunctionDecl [[ADDR_12]]  line:11:1 also_after[implementation={vendor(llvm)}] 'int ({{.*}})'
+// CHECK-NEXT: | `-CompoundStmt [[ADDR_13:0x[a-z0-9]*]] 
+// CHECK-NEXT: |   `-ReturnStmt [[ADDR_14:0x[a-z0-9]*]] 
+// CHECK-NEXT: | `-IntegerLiteral [[ADDR_15:0x[a-z0-9]*]]  'int' 2
+// CHECK-NEXT: |-FunctionDecl [[ADDR_16:0x[a-z0-9]*]]  col:5 implicit also_after 'int (int &)'
+// CHECK-NEXT: | |-ParmVarDecl [[ADDR_17:0x[a-z0-9]*]]  col:20 'int &'
+// CHECK-NEXT: | `-OMPDeclareVariantAttr [[ADDR_18:0x[a-z0-9]*]] <> Implicit implementation={vendor(score(100): llvm)}
+// CHECK-NEXT: |   `-DeclRefExpr [[ADDR_19:0x[a-z0-9]*]]  'int (int &)' {{.*}}Function [[ADDR_20:0x[a-z0-9]*]] 'also_after[implementation={vendor(llvm)}]' 'int (int &)'
+// CHECK-NEXT: |-FunctionDecl [[ADDR_20]]  line:14:1 also_after[implementation={vendor(llvm)}] 'int (int &)'
+// CHECK-NEXT: | |-ParmVarDecl [[ADDR_17]]  col:20 'int &'
+// CHECK-NEXT: | `-CompoundStmt [[ADDR_21:0x[a-z0-9]*]] 
+// CHECK-NEXT: |   `-ReturnStmt [[ADDR_22:0x[a-z0-9]*]] 
+// CHECK-NEXT: | `-IntegerLiteral [[ADDR_23:0x[a-z0-9]*]]  'int' 3
+// CHECK-NEXT: |-FunctionDecl [[ADDR_24:0x[a-z0-9]*]]  col:5 implicit used also_after 'int (double &)'
+// CHECK-NEXT: | |-ParmVarDecl [[ADDR_25:0x[a-z0-9]*]]  col:23 'double &'
+// CHECK-NEXT: | `-OMPDeclareVariantAttr [[ADDR_26:0x[a-z0-9]*]] <> Implicit implementation={vendor(score(100): llvm)}
+// CHECK-NEXT: |   `-DeclRefExpr [[ADDR_27:0x[a-z0-9]*]]  'int (double &)' {{.*}}Function [[ADDR_28:0x[a-z0-9]*]] 'also_after[implementation={vendor(llvm)}]' 'int (double &)'
+// CHECK-NEXT: |-FunctionDecl [[ADDR_28]]  line:17:1 also_after[implementation={vendor(llvm)}] 'int (double &)'
+// CHECK-NEXT: | |-ParmVarDecl [[ADDR_25]]  col:23 'double &'
+// CHECK-NEXT: | `-CompoundStmt [[ADDR_29:0x[a-z0-9]*]] 
+// CHECK-NEXT: |   `-ReturnStmt [[ADDR_30:0x[a-z0-9]*]] 
+// CHECK-NEXT: | `-IntegerLiteral [[ADDR_31:0x[a-z0-9]*]]  'int' 0
+// CHECK-NEXT: |-FunctionDecl [[ADDR_8]]  line:22:1 also_before[implementation={vendor(llvm)}] 'int &({{.*}})'
+// CHECK-NEXT: | 

[PATCH] D108775: [CMake] Change -DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=off to -DLLVM_ENABLE_NEW_PASS_MANAGER=off

2021-08-26 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay created this revision.
MaskRay added reviewers: aeubanks, phosek, tstellar.
Herald added a subscriber: mgorny.
MaskRay requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

LLVM_ENABLE_NEW_PASS_MANAGER is set to ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER, so
-D has no effect.

Change the cache variable to LLVM_ENABLE_NEW_PASS_MANAGER instead.

Also give a warning that -DLLVM_ENABLE_NEW_PASS_MANAGER=off is deprecated.

Intended for main and release/13.x


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D108775

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake
  clang/cmake/caches/Fuchsia.cmake
  llvm/CMakeLists.txt
  llvm/docs/NewPassManager.rst


Index: llvm/docs/NewPassManager.rst
===
--- llvm/docs/NewPassManager.rst
+++ llvm/docs/NewPassManager.rst
@@ -449,7 +449,7 @@
 
 For the optimization pipeline, the new PM is the default PM. The legacy PM is
 available for the optimization pipeline either by setting the CMake flag
-``-DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=OFF`` when building LLVM, or by
+``-DLLVM_ENABLE_NEW_PASS_MANAGER=OFF`` when building LLVM, or by
 various compiler/linker flags, e.g. ``-flegacy-pass-manager`` for ``clang``.
 
 There will be efforts to deprecate and remove the legacy PM for the
Index: llvm/CMakeLists.txt
===
--- llvm/CMakeLists.txt
+++ llvm/CMakeLists.txt
@@ -706,8 +706,13 @@
 endif()
 option(LLVM_ENABLE_PLUGINS "Enable plugin support" 
${LLVM_ENABLE_PLUGINS_default})
 
-set(ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER TRUE CACHE BOOL
+set(LLVM_ENABLE_NEW_PASS_MANAGER TRUE CACHE BOOL
   "Enable the new pass manager by default.")
+if(NOT LLVM_ENABLE_NEW_PASS_MANAGER)
+  message(WARNING "Using the legacy pass manager for the optimization pipeline"
+  " is deprecated. The functionality will degrade over time 
and"
+  " be removed in a future release.")
+endif()
 
 include(HandleLLVMOptions)
 
@@ -846,10 +851,6 @@
   set_property(GLOBAL APPEND PROPERTY LLVM_EXPORTS tf_xla_runtime)
 endif()
 
-# Keep the legacy CMake flag ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER for
-# compatibility.
-set(LLVM_ENABLE_NEW_PASS_MANAGER ${ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER})
-
 # Configure the three LLVM configuration header files.
 configure_file(
   ${LLVM_MAIN_INCLUDE_DIR}/llvm/Config/config.h.cmake
Index: clang/cmake/caches/Fuchsia.cmake
===
--- clang/cmake/caches/Fuchsia.cmake
+++ clang/cmake/caches/Fuchsia.cmake
@@ -32,7 +32,6 @@
 set(CLANG_ENABLE_STATIC_ANALYZER ON CACHE BOOL "")
 set(CLANG_PLUGIN_SUPPORT OFF CACHE BOOL "")
 
-set(ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER ON CACHE BOOL "")
 set(ENABLE_LINKER_BUILD_ID ON CACHE BOOL "")
 set(ENABLE_X86_RELAX_RELOCATIONS ON CACHE BOOL "")
 
Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -41,7 +41,6 @@
 set(CLANG_ENABLE_STATIC_ANALYZER ON CACHE BOOL "")
 set(CLANG_PLUGIN_SUPPORT OFF CACHE BOOL "")
 
-set(ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER ON CACHE BOOL "")
 set(ENABLE_LINKER_BUILD_ID ON CACHE BOOL "")
 set(ENABLE_X86_RELAX_RELOCATIONS ON CACHE BOOL "")
 


Index: llvm/docs/NewPassManager.rst
===
--- llvm/docs/NewPassManager.rst
+++ llvm/docs/NewPassManager.rst
@@ -449,7 +449,7 @@
 
 For the optimization pipeline, the new PM is the default PM. The legacy PM is
 available for the optimization pipeline either by setting the CMake flag
-``-DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=OFF`` when building LLVM, or by
+``-DLLVM_ENABLE_NEW_PASS_MANAGER=OFF`` when building LLVM, or by
 various compiler/linker flags, e.g. ``-flegacy-pass-manager`` for ``clang``.
 
 There will be efforts to deprecate and remove the legacy PM for the
Index: llvm/CMakeLists.txt
===
--- llvm/CMakeLists.txt
+++ llvm/CMakeLists.txt
@@ -706,8 +706,13 @@
 endif()
 option(LLVM_ENABLE_PLUGINS "Enable plugin support" ${LLVM_ENABLE_PLUGINS_default})
 
-set(ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER TRUE CACHE BOOL
+set(LLVM_ENABLE_NEW_PASS_MANAGER TRUE CACHE BOOL
   "Enable the new pass manager by default.")
+if(NOT LLVM_ENABLE_NEW_PASS_MANAGER)
+  message(WARNING "Using the legacy pass manager for the optimization pipeline"
+  " is deprecated. The functionality will degrade over time and"
+  " be removed in a future release.")
+endif()
 
 include(HandleLLVMOptions)
 
@@ -846,10 +851,6 @@
   set_property(GLOBAL APPEND PROPERTY LLVM_EXPORTS tf_xla_runtime)
 endif()
 
-# Keep the legacy CMake flag ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER for
-# compatibility.
-set(LLVM_ENABLE_NEW_PASS_MANAGER 

[PATCH] D108774: [OpenMP][FIX] Allow declare variant to work with reference types

2021-08-26 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert updated this revision to Diff 368940.
jdoerfert added a comment.

Add test


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108774

Files:
  clang/lib/AST/ASTContext.cpp
  clang/test/AST/ast-dump-openmp-begin-declare-variant_reference.cpp

Index: clang/test/AST/ast-dump-openmp-begin-declare-variant_reference.cpp
===
--- /dev/null
+++ clang/test/AST/ast-dump-openmp-begin-declare-variant_reference.cpp
@@ -0,0 +1,146 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fopenmp -verify -ast-dump %s   | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fopenmp -verify -ast-dump %s -x c++| FileCheck %s
+// expected-no-diagnostics
+
+int Good, Bad;
+int& also_before() {
+  return Bad;
+}
+
+#pragma omp begin declare variant match(implementation={vendor(score(100):llvm)})
+int also_after(void) {
+  return 2;
+}
+int also_after(int&) {
+  return 3;
+}
+int also_after(double&) {
+  return 0;
+}
+#pragma omp end declare variant
+#pragma omp begin declare variant match(implementation={vendor(score(0):llvm)})
+int& also_before() {
+  return Good;
+}
+#pragma omp end declare variant
+
+int also_after(void) {
+  return 4;
+}
+int also_after(int) {
+  return 5;
+}
+int also_after(double&) {
+  return 6;
+}
+
+int test1() {
+  // Should return 0.
+  double d;
+  return also_after(d);
+}
+
+int test2() {
+  // Should return 0.
+  return _before() == 
+}
+
+int test() {
+  // Should return 0.
+  return test1() + test2();
+}
+
+// CHECK:  |-VarDecl [[ADDR_0:0x[a-z0-9]*]] <{{.*}}, col:5> col:5 used Good 'int'
+// CHECK-NEXT: |-VarDecl [[ADDR_1:0x[a-z0-9]*]]  col:11 used Bad 'int'
+// CHECK-NEXT: |-FunctionDecl [[ADDR_2:0x[a-z0-9]*]]  line:6:6 used also_before 'int &({{.*}})'
+// CHECK-NEXT: | |-CompoundStmt [[ADDR_3:0x[a-z0-9]*]] 
+// CHECK-NEXT: | | `-ReturnStmt [[ADDR_4:0x[a-z0-9]*]] 
+// CHECK-NEXT: | |   `-DeclRefExpr [[ADDR_5:0x[a-z0-9]*]]  'int' {{.*}}Var [[ADDR_1]] 'Bad' 'int'
+// CHECK-NEXT: | `-OMPDeclareVariantAttr [[ADDR_6:0x[a-z0-9]*]] <> Implicit implementation={vendor(score(0): llvm)}
+// CHECK-NEXT: |   `-DeclRefExpr [[ADDR_7:0x[a-z0-9]*]]  'int &({{.*}})' {{.*}}Function [[ADDR_8:0x[a-z0-9]*]] 'also_before[implementation={vendor(llvm)}]' 'int &({{.*}})'
+// CHECK-NEXT: |-FunctionDecl [[ADDR_9:0x[a-z0-9]*]]  col:5 implicit also_after 'int ({{.*}})'
+// CHECK-NEXT: | `-OMPDeclareVariantAttr [[ADDR_10:0x[a-z0-9]*]] <> Implicit implementation={vendor(score(100): llvm)}
+// CHECK-NEXT: |   `-DeclRefExpr [[ADDR_11:0x[a-z0-9]*]]  'int ({{.*}})' {{.*}}Function [[ADDR_12:0x[a-z0-9]*]] 'also_after[implementation={vendor(llvm)}]' 'int ({{.*}})'
+// CHECK-NEXT: |-FunctionDecl [[ADDR_12]]  line:11:1 also_after[implementation={vendor(llvm)}] 'int ({{.*}})'
+// CHECK-NEXT: | `-CompoundStmt [[ADDR_13:0x[a-z0-9]*]] 
+// CHECK-NEXT: |   `-ReturnStmt [[ADDR_14:0x[a-z0-9]*]] 
+// CHECK-NEXT: | `-IntegerLiteral [[ADDR_15:0x[a-z0-9]*]]  'int' 2
+// CHECK-NEXT: |-FunctionDecl [[ADDR_16:0x[a-z0-9]*]]  col:5 implicit also_after 'int (int &)'
+// CHECK-NEXT: | |-ParmVarDecl [[ADDR_17:0x[a-z0-9]*]]  col:20 'int &'
+// CHECK-NEXT: | `-OMPDeclareVariantAttr [[ADDR_18:0x[a-z0-9]*]] <> Implicit implementation={vendor(score(100): llvm)}
+// CHECK-NEXT: |   `-DeclRefExpr [[ADDR_19:0x[a-z0-9]*]]  'int (int &)' {{.*}}Function [[ADDR_20:0x[a-z0-9]*]] 'also_after[implementation={vendor(llvm)}]' 'int (int &)'
+// CHECK-NEXT: |-FunctionDecl [[ADDR_20]]  line:14:1 also_after[implementation={vendor(llvm)}] 'int (int &)'
+// CHECK-NEXT: | |-ParmVarDecl [[ADDR_17]]  col:20 'int &'
+// CHECK-NEXT: | `-CompoundStmt [[ADDR_21:0x[a-z0-9]*]] 
+// CHECK-NEXT: |   `-ReturnStmt [[ADDR_22:0x[a-z0-9]*]] 
+// CHECK-NEXT: | `-IntegerLiteral [[ADDR_23:0x[a-z0-9]*]]  'int' 3
+// CHECK-NEXT: |-FunctionDecl [[ADDR_24:0x[a-z0-9]*]]  col:5 implicit used also_after 'int (double &)'
+// CHECK-NEXT: | |-ParmVarDecl [[ADDR_25:0x[a-z0-9]*]]  col:23 'double &'
+// CHECK-NEXT: | `-OMPDeclareVariantAttr [[ADDR_26:0x[a-z0-9]*]] <> Implicit implementation={vendor(score(100): llvm)}
+// CHECK-NEXT: |   `-DeclRefExpr [[ADDR_27:0x[a-z0-9]*]]  'int (double &)' {{.*}}Function [[ADDR_28:0x[a-z0-9]*]] 'also_after[implementation={vendor(llvm)}]' 'int (double &)'
+// CHECK-NEXT: |-FunctionDecl [[ADDR_28]]  line:17:1 also_after[implementation={vendor(llvm)}] 'int (double &)'
+// CHECK-NEXT: | |-ParmVarDecl [[ADDR_25]]  col:23 'double &'
+// CHECK-NEXT: | `-CompoundStmt [[ADDR_29:0x[a-z0-9]*]] 
+// CHECK-NEXT: |   `-ReturnStmt [[ADDR_30:0x[a-z0-9]*]] 
+// CHECK-NEXT: | `-IntegerLiteral [[ADDR_31:0x[a-z0-9]*]]  'int' 0
+// CHECK-NEXT: |-FunctionDecl [[ADDR_8]]  line:22:1 also_before[implementation={vendor(llvm)}] 'int &({{.*}})'
+// CHECK-NEXT: | `-CompoundStmt [[ADDR_32:0x[a-z0-9]*]] 
+// CHECK-NEXT: |   `-ReturnStmt [[ADDR_33:0x[a-z0-9]*]] 
+// CHECK-NEXT: | `-DeclRefExpr 

[PATCH] D108774: [OpenMP][FIX] Allow declare variant to work with reference types

2021-08-26 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert created this revision.
jdoerfert added reviewers: JonChesterfield, ABataev, pdhaliwal, aaron.ballman.
Herald added subscribers: guansong, bollu, yaxunl.
jdoerfert requested review of this revision.
Herald added a subscriber: sstefan1.
Herald added a project: clang.

Reference types in the return or parameter position did cause the OpenMP
declare variant overload reasoning to give up. We should allow them as
we allow any other type.

This should fix the bug reported on the mailing list:
https://lists.llvm.org/pipermail/openmp-dev/2021-August/004094.html


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D108774

Files:
  clang/lib/AST/ASTContext.cpp


Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -9680,11 +9680,16 @@
 QualType ASTContext::mergeTypes(QualType LHS, QualType RHS,
 bool OfBlockPointer,
 bool Unqualified, bool BlockReturnType) {
+  // For C++ we will not reach this code with reference types (see below),
+  // for OpenMP variant call overloading we might.
+  //
   // C++ [expr]: If an expression initially has the type "reference to T", the
   // type is adjusted to "T" prior to any further analysis, the expression
   // designates the object or function denoted by the reference, and the
   // expression is an lvalue unless the reference is an rvalue reference and
   // the expression is a function call (possibly inside parentheses).
+  if (LHS->getAs() && RHS->getAs())
+return mergeTypes(LHS->getAs()->getPointeeType() , 
RHS->getAs()->getPointeeType(), OfBlockPointer, Unqualified, 
BlockReturnType);
   if (LHS->getAs() || RHS->getAs())
 return {};
 


Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -9680,11 +9680,16 @@
 QualType ASTContext::mergeTypes(QualType LHS, QualType RHS,
 bool OfBlockPointer,
 bool Unqualified, bool BlockReturnType) {
+  // For C++ we will not reach this code with reference types (see below),
+  // for OpenMP variant call overloading we might.
+  //
   // C++ [expr]: If an expression initially has the type "reference to T", the
   // type is adjusted to "T" prior to any further analysis, the expression
   // designates the object or function denoted by the reference, and the
   // expression is an lvalue unless the reference is an rvalue reference and
   // the expression is a function call (possibly inside parentheses).
+  if (LHS->getAs() && RHS->getAs())
+return mergeTypes(LHS->getAs()->getPointeeType() , RHS->getAs()->getPointeeType(), OfBlockPointer, Unqualified, BlockReturnType);
   if (LHS->getAs() || RHS->getAs())
 return {};
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] d2d7a90 - [DebugInfo] convert btf_tag attrs to DI annotations for DIGlobalVariable

2021-08-26 Thread Yonghong Song via cfe-commits

Author: Yonghong Song
Date: 2021-08-26T10:36:33-07:00
New Revision: d2d7a90ceded94251905b7adcd5eb2ac5191896f

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

LOG: [DebugInfo] convert btf_tag attrs to DI annotations for DIGlobalVariable

Generate btf_tag annotations for DIGlobalVariable. The annotations
are represented as an DINodeArray in DebugInfo.

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

Added: 
clang/test/CodeGen/attr-btf_tag-diglobalvariable.c

Modified: 
clang/lib/CodeGen/CGDebugInfo.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGDebugInfo.cpp 
b/clang/lib/CodeGen/CGDebugInfo.cpp
index 57f915028dde..2de933f65800 100644
--- a/clang/lib/CodeGen/CGDebugInfo.cpp
+++ b/clang/lib/CodeGen/CGDebugInfo.cpp
@@ -4828,12 +4828,13 @@ void 
CGDebugInfo::EmitGlobalVariable(llvm::GlobalVariable *Var,
 }
 AppendAddressSpaceXDeref(AddressSpace, Expr);
 
+llvm::DINodeArray Annotations = CollectBTFTagAnnotations(D);
 GVE = DBuilder.createGlobalVariableExpression(
 DContext, DeclName, LinkageName, Unit, LineNo, getOrCreateType(T, 
Unit),
 Var->hasLocalLinkage(), true,
 Expr.empty() ? nullptr : DBuilder.createExpression(Expr),
 getOrCreateStaticDataMemberDeclarationOrNull(D), TemplateParameters,
-Align);
+Align, Annotations);
 Var->addDebugInfo(GVE);
   }
   DeclCache[D->getCanonicalDecl()].reset(GVE);

diff  --git a/clang/test/CodeGen/attr-btf_tag-diglobalvariable.c 
b/clang/test/CodeGen/attr-btf_tag-diglobalvariable.c
new file mode 100644
index ..e8b20a202990
--- /dev/null
+++ b/clang/test/CodeGen/attr-btf_tag-diglobalvariable.c
@@ -0,0 +1,29 @@
+// REQUIRES: x86-registered-target
+// RUN: %clang -target x86_64 -g -S -emit-llvm -o - %s | FileCheck %s
+
+#define __tag1 __attribute__((btf_tag("tag1")))
+#define __tag2 __attribute__((btf_tag("tag2")))
+
+struct t1 {
+  int a;
+};
+struct t1 g1 __tag1 __tag2;
+
+extern struct t1 g2 __tag1 __tag2;
+struct t1 g2;
+
+// CHECK: distinct !DIGlobalVariable(name: "g1", scope: ![[#]], file: ![[#]], 
line: [[#]], type: ![[#]], isLocal: false, isDefinition: true, annotations: 
![[ANNOT:[0-9]+]])
+// CHECK: distinct !DIGlobalVariable(name: "g2", scope: ![[#]], file: ![[#]], 
line: [[#]], type: ![[#]], isLocal: false, isDefinition: true, annotations: 
![[ANNOT]])
+// CHECK: ![[ANNOT]] = !{![[TAG1:[0-9]+]], ![[TAG2:[0-9]+]]}
+// CHECK: ![[TAG1]] = !{!"btf_tag", !"tag1"}
+// CHECK: ![[TAG2]] = !{!"btf_tag", !"tag2"}
+
+extern struct t1 g3 __tag1;
+struct t1 g3 __tag2;
+
+// CHECK: distinct !DIGlobalVariable(name: "g3", scope: ![[#]], file: ![[#]], 
line: [[#]], type: ![[#]], isLocal: false, isDefinition: true, annotations: 
![[ANNOT]])
+
+extern struct t1 g4;
+struct t1 g4 __tag1 __tag2;
+
+// CHECK: distinct !DIGlobalVariable(name: "g4", scope: ![[#]], file: ![[#]], 
line: [[#]], type: ![[#]], isLocal: false, isDefinition: true, annotations: 
![[ANNOT]])



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


[PATCH] D102449: [WIP][Clang][OpenMP] Add the support for compare clause in atomic directive

2021-08-26 Thread Carlo Bertolli via Phabricator via cfe-commits
carlo.bertolli added a comment.

Thanks for uploading this.

I tried it locally and it is missing proper parsing +sema of the cond-expr-stmt 
and cond-update-stmt as indicate in the openmp 5.1 spec's. I am sure you are 
aware of this and this is still WIP.
Do you plan to add support for that? The regression test is not exposing 
conditional statements, but update ones, so it is not really testing what it 
should.

You might also want to split parse+sema support from codegen, if it helps.

Many thanks again!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102449

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


[PATCH] D108243: Revert "Avoid needlessly copying a block to the heap when a block literal"

2021-08-26 Thread James Y Knight via Phabricator via cfe-commits
jyknight added a comment.

Ping. Any comment from Apple folks?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108243

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


[PATCH] D108693: [OpenCL] Defines helper function for kernel language compatible OpenCL version

2021-08-26 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia accepted this revision.
Anastasia added a comment.
This revision is now accepted and ready to land.

LGTM! Thanks!

This is a very nice clean up!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108693

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


[PATCH] D108704: [OpenCL] Define OpenCL 3.0 optional core features in C++ for OpenCL 2021

2021-08-26 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia accepted this revision.
Anastasia added a comment.
This revision is now accepted and ready to land.

LGTM! Thanks


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108704

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


[PATCH] D106619: [Clang][LLVM] generate btf_tag annotations for DIGlobalVariable

2021-08-26 Thread Yonghong Song via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG30c288489ae5: [DebugInfo] generate btf_tag annotations for 
DIGlobalVariable (authored by yonghong-song).

Changed prior to commit:
  https://reviews.llvm.org/D106619?vs=367710=368920#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106619

Files:
  llvm/include/llvm/IR/DIBuilder.h
  llvm/include/llvm/IR/DebugInfoMetadata.h
  llvm/lib/AsmParser/LLParser.cpp
  llvm/lib/Bitcode/Reader/MetadataLoader.cpp
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/IR/AsmWriter.cpp
  llvm/lib/IR/DIBuilder.cpp
  llvm/lib/IR/DebugInfoMetadata.cpp
  llvm/lib/IR/LLVMContextImpl.h
  llvm/test/Bitcode/attr-btf_tag-diglobalvariable.ll
  llvm/unittests/IR/MetadataTest.cpp

Index: llvm/unittests/IR/MetadataTest.cpp
===
--- llvm/unittests/IR/MetadataTest.cpp
+++ llvm/unittests/IR/MetadataTest.cpp
@@ -2574,7 +2574,8 @@
 
   auto *N = DIGlobalVariable::get(
   Context, Scope, Name, LinkageName, File, Line, Type, IsLocalToUnit,
-  IsDefinition, StaticDataMemberDeclaration, templateParams, AlignInBits);
+  IsDefinition, StaticDataMemberDeclaration, templateParams, AlignInBits,
+  nullptr);
 
   EXPECT_EQ(dwarf::DW_TAG_variable, N->getTag());
   EXPECT_EQ(Scope, N->getScope());
@@ -2591,52 +2592,54 @@
   EXPECT_EQ(N, DIGlobalVariable::get(Context, Scope, Name, LinkageName, File,
  Line, Type, IsLocalToUnit, IsDefinition,
  StaticDataMemberDeclaration,
- templateParams, AlignInBits));
+ templateParams, AlignInBits, nullptr));
 
   EXPECT_NE(N, DIGlobalVariable::get(
Context, getSubprogram(), Name, LinkageName, File, Line,
Type, IsLocalToUnit, IsDefinition,
-   StaticDataMemberDeclaration, templateParams, AlignInBits));
+   StaticDataMemberDeclaration, templateParams, AlignInBits,
+   nullptr));
   EXPECT_NE(N, DIGlobalVariable::get(Context, Scope, "other", LinkageName, File,
  Line, Type, IsLocalToUnit, IsDefinition,
  StaticDataMemberDeclaration,
- templateParams, AlignInBits));
+ templateParams, AlignInBits, nullptr));
   EXPECT_NE(N, DIGlobalVariable::get(Context, Scope, Name, "other", File, Line,
  Type, IsLocalToUnit, IsDefinition,
  StaticDataMemberDeclaration,
- templateParams, AlignInBits));
+ templateParams, AlignInBits, nullptr));
   EXPECT_NE(N, DIGlobalVariable::get(Context, Scope, Name, LinkageName,
  getFile(), Line, Type, IsLocalToUnit,
  IsDefinition, StaticDataMemberDeclaration,
- templateParams, AlignInBits));
+ templateParams, AlignInBits, nullptr));
   EXPECT_NE(N, DIGlobalVariable::get(Context, Scope, Name, LinkageName, File,
  Line + 1, Type, IsLocalToUnit,
  IsDefinition, StaticDataMemberDeclaration,
- templateParams, AlignInBits));
+ templateParams, AlignInBits, nullptr));
   EXPECT_NE(N, DIGlobalVariable::get(Context, Scope, Name, LinkageName, File,
  Line, getDerivedType(), IsLocalToUnit,
  IsDefinition, StaticDataMemberDeclaration,
- templateParams, AlignInBits));
+ templateParams, AlignInBits, nullptr));
   EXPECT_NE(N, DIGlobalVariable::get(Context, Scope, Name, LinkageName, File,
  Line, Type, !IsLocalToUnit, IsDefinition,
  StaticDataMemberDeclaration,
- templateParams, AlignInBits));
+ templateParams, AlignInBits, nullptr));
   EXPECT_NE(N, DIGlobalVariable::get(Context, Scope, Name, LinkageName, File,
  Line, Type, IsLocalToUnit, !IsDefinition,
  StaticDataMemberDeclaration,
- templateParams, AlignInBits));
+ templateParams, AlignInBits, nullptr));
   EXPECT_NE(N, DIGlobalVariable::get(Context, Scope, Name, LinkageName, File,
  Line, 

[PATCH] D107769: [OpenCL] Make generic addrspace optional for -fdeclare-opencl-builtins

2021-08-26 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added a comment.

In D107769#2960441 , @svenvh wrote:

> I have done an alternative spin of this patch: instead of introducing 
> `RequireDisabledExtension`, simply always make the `private`, `global`, and 
> `local` overloads available.  This makes tablegen diverge from `opencl-c.h` 
> though.  Perhaps we should also always add make the `private`, `global`, and 
> `local` overloads available in `opencl-c.h`?

Yes, we could do this indeed as a clang extension. I don't think this will 
impact the user code. However, this means vendors will have to add extra 
overloads in OpenCL 2.0 mode?


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

https://reviews.llvm.org/D107769

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


[PATCH] D70172: [CUDA][HIP][OpenMP] Emit deferred diagnostics by a post-parsing AST travese

2021-08-26 Thread Wei Wang via Phabricator via cfe-commits
weiwang added a comment.

In D70172#2964118 , @sugak wrote:

> Hi @yaxunl! I'm working on upgrading a large codebase from LLVM-9 to LLVM-12. 
> I noticed on average 10% compilation speed regression that seems to be caused 
> this change. We use Clang modules and historically provide `-fopenmp` 
> compiler flag by default. The problem seems to be that compiling and 
> importing modules is now slower, with the generated modules size increased by 
> 2X. llvm-bcanalyzer tool shows that it's dominated by 
> `DECLS_TO_CHECK_FOR_DEFERRED_DIAGS`.  If I understand it right, your change 
> is only relevant when target offloading is used. I inspected all of `#pragma 
> omp` directives and can confirm that we don't use it.
>
> I see that most of this code is gated by OpenMP flag. I wonder if there is a 
> finer grain way to enable openmp parallel code generation without target 
> offloading? Would it make sense to extend this code to check if 
> `-fopenom-targets` is set before recording 
> `DECLS_TO_CHECK_FOR_DEFERRED_DIAGS`?
>
> Note, this was measured with @weiwang's https://reviews.llvm.org/D101793.

We did an internal measurement by not adding decls into deferred diags, and 
that resolves the build regression. Wonder if we can have a special case for 
emitting diag as they are encountered when everything is on host side.


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

https://reviews.llvm.org/D70172

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


[PATCH] D105167: [analyzer] Fix HTML report deduplication.

2021-08-26 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added a comment.

In D105167#2949521 , @ASDenysPetrov 
wrote:

> Nice work! Unfortunately I'm not able to run tests on my Windows env, but 
> I've run you tests files manually. It works for me.
>
> P.S. BTW, is there any workarounds to make current tests supported on 
> Windows? I know there is //REQUIRES// instruction 
> (https://llvm.org/docs/TestingGuide.html#constraining-test-execution) but I 
> didn't find any sufficient description of it.

Yes, you can always remove the `REQUIRES:` directive. The problem with 
generally enabling these tests on Windows is that scan-build is written in Perl 
and the Perl interpreter isn't shipped with Windows by default. Nothing else in 
LLVM is written in Perl so requiring a Perl installation to run LLVM tests just 
for this single use case is counter-productive.




Comment at: clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp:286-287
+  // but the stable report filename is still more verbose.
+  // We should rename the option ("verbose" filename?) but it will break
+  // people's workflows.
+  if (DiagOpts.ShouldWriteStableReportFilename) {

ASDenysPetrov wrote:
> vsavchenko wrote:
> > Can we make a mirror for this option and mark the other one as deprecated?
> Nice idea. I'm in favor of a mirorring.
The new option is `-analyzer-config verbose-report-filename=true` and the old 
option is preserved and acts exactly the same; the help text says that it's 
deprecated.



Comment at: clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp:300
+
+  filename << StringRef(getIssueHash(D, PP)).substr(0, 6).str() << ".html";
+  llvm::sys::path::append(ResultPath, Directory, filename.str());

ASDenysPetrov wrote:
> Do you think 6 trimmed characters are enough to avoid collisions?
It's basically same as before. Previously these 6 digits were completely 
random, now they're chunks of MD5 hashes of the real thing which is probably as 
random.

That's 16.7 million variants. The probability of collision on 6 digits with 100 
warnings is around 0.0001%, with 1000 warnings it goes up to 3% ([[ 
https://en.wikipedia.org/wiki/Birthday_problem | Birthday Problem]]). Even 
though 1000 warnings are a real possibility on a huge project (eg., LLVM or 
WebKit), this is way above the point where you care about collisions.

I think there's nothing that prevents us from bumping it (at least in the 
non-verbose filename mode; in the verbose filename mode it may cause slightly 
more breakages in the case where it's close to hitting the file system's 
filename length limit). Bumping from 6 digits to 8 digits would reduce the 
collision probability on 1000 warnings to 0.0001%. I'll think about it a bit 
more :)


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

https://reviews.llvm.org/D105167

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


[PATCH] D105167: [analyzer] Fix HTML report deduplication.

2021-08-26 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ updated this revision to Diff 368917.
NoQ marked 4 inline comments as done.
NoQ added a comment.

Address review comments!


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

https://reviews.llvm.org/D105167

Files:
  clang/include/clang/Analysis/PathDiagnostic.h
  clang/include/clang/StaticAnalyzer/Core/AnalyzerOptions.def
  clang/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
  clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
  clang/test/Analysis/analyzer-config.c
  clang/test/Analysis/scan-build/Inputs/deduplication/1.c
  clang/test/Analysis/scan-build/Inputs/deduplication/2.c
  clang/test/Analysis/scan-build/Inputs/deduplication/header.h
  clang/test/Analysis/scan-build/deduplication.test
  clang/test/Analysis/scan-build/rebuild_index/rebuild_index.test
  clang/test/Analysis/scan-build/rebuild_index/report-3.html
  clang/test/Analysis/scan-build/rebuild_index/subdirectory/report-3.html
  clang/test/Analysis/scan-build/rebuild_index/subdirectory/report-4.html
  clang/tools/scan-build/bin/scan-build

Index: clang/tools/scan-build/bin/scan-build
===
--- clang/tools/scan-build/bin/scan-build
+++ clang/tools/scan-build/bin/scan-build
@@ -14,7 +14,6 @@
 use strict;
 use warnings;
 use FindBin qw($RealBin);
-use Digest::MD5;
 use File::Basename;
 use File::Find;
 use File::Copy qw(copy);
@@ -268,27 +267,6 @@
   $ENV{'CCC_ANALYZER_HTML'} = $Dir;
 }
 
-####
-# ComputeDigest - Compute a digest of the specified file.
-####
-
-sub ComputeDigest {
-  my $FName = shift;
-  DieDiag("Cannot read $FName to compute Digest.\n") if (! -r $FName);
-
-  # Use Digest::MD5.  We don't have to be cryptographically secure.  We're
-  # just looking for duplicate files that come from a non-malicious source.
-  # We use Digest::MD5 because it is a standard Perl module that should
-  # come bundled on most systems.
-  open(FILE, $FName) or DieDiag("Cannot open $FName when computing Digest.\n");
-  binmode FILE;
-  my $Result = Digest::MD5->new->addfile(*FILE)->hexdigest;
-  close(FILE);
-
-  # Return the digest.
-  return $Result;
-}
-
 ####
 #  UpdatePrefix - Compute the common prefix of files.
 ####
@@ -374,8 +352,6 @@
 # Sometimes a source file is scanned more than once, and thus produces
 # multiple error reports.  We use a cache to solve this problem.
 
-my %AlreadyScanned;
-
 sub ScanFile {
 
   my $Index = shift;
@@ -383,19 +359,6 @@
   my $FName = shift;
   my $Stats = shift;
 
-  # Compute a digest for the report file.  Determine if we have already
-  # scanned a file that looks just like it.
-
-  my $digest = ComputeDigest("$Dir/$FName");
-
-  if (defined $AlreadyScanned{$digest}) {
-# Redundant file.  Remove it.
-unlink("$Dir/$FName");
-return;
-  }
-
-  $AlreadyScanned{$digest} = 1;
-
   # At this point the report file is not world readable.  Make it happen.
   chmod(0644, "$Dir/$FName");
 
Index: clang/test/Analysis/scan-build/rebuild_index/subdirectory/report-4.html
===
--- clang/test/Analysis/scan-build/rebuild_index/subdirectory/report-4.html
+++ /dev/null
@@ -1,8 +0,0 @@
-
-
-
-
-
-
-
-
Index: clang/test/Analysis/scan-build/rebuild_index/subdirectory/report-3.html
===
--- /dev/null
+++ clang/test/Analysis/scan-build/rebuild_index/subdirectory/report-3.html
@@ -0,0 +1,8 @@
+
+
+
+
+
+
+
+
Index: clang/test/Analysis/scan-build/rebuild_index/report-3.html
===
--- clang/test/Analysis/scan-build/rebuild_index/report-3.html
+++ /dev/null
@@ -1,8 +0,0 @@
-
-
-
-
-
-
-
-
Index: clang/test/Analysis/scan-build/rebuild_index/rebuild_index.test
===
--- clang/test/Analysis/scan-build/rebuild_index/rebuild_index.test
+++ clang/test/Analysis/scan-build/rebuild_index/rebuild_index.test
@@ -4,9 +4,8 @@
 RUN: rm -rf %t.output_dir && mkdir %t.output_dir
 RUN: cp %S/report-1.html %t.output_dir
 RUN: cp %S/report-2.html %t.output_dir
-RUN: cp %S/report-3.html %t.output_dir
 RUN: mkdir %t.output_dir/subdirectory
-RUN: cp %S/subdirectory/report-4.html %t.output_dir/subdirectory
+RUN: cp %S/subdirectory/report-3.html %t.output_dir/subdirectory
 
 RUN: %scan-build --generate-index-only %t.output_dir
 
@@ -15,16 +14,13 @@
 CHECK-FILES:  index.html
 CHECK-FILES-NEXT: report-1.html
 CHECK-FILES-NEXT: report-2.html
-
-// report-3.html is a duplicate of report-1.html so it's not present.
-CHECK-FILES-NOT:  report-3.html
 CHECK-FILES-NEXT: scanview.css
 CHECK-FILES-NEXT: sorttable.js
 

[PATCH] D108695: [analyzer][NFCI] Allow clients of NoStateChangeFuncVisitor to check entire function calls, rather than each ExplodedNode in it

2021-08-26 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added a comment.

Would this work correctly when the property is changed but then reverted to its 
original state? This probably can't happen to MallocChecker (what has been 
freed cannot be unfreed) but it may happen to eg. PthreadLockChecker or to, 
well, Stores. In such cases it would be incorrect to say "returning without 
changing the state".




Comment at: clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:370
+  while (N && !N->getLocationAs())
+N = N->getFirstSucc();
+  return N;

This is the right successor because we're in a heavily trimmed exploded graph, 
right?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108695

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


[PATCH] D108742: Reclassify form-feed and vertical tab as vertical WS for the purposes of lexing.

2021-08-26 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits
dexonsmith added a comment.

Thanks for looking at this — I'm just reviewing the test changes in the 
minimizer (assuming the code change is the right thing to do).




Comment at: 
clang/unittests/Lex/DependencyDirectivesSourceMinimizerTest.cpp:170-173
   ASSERT_FALSE(
-  minimizeSourceToDependencyDirectives("#define MACRO(a\\\n"
+  minimizeSourceToDependencyDirectives("#define MACRO(a
\\\n\\\v\\\f"
"  )",
Out));

Please don't modify this assertion to test `\v` and `\f`. Instead add new 
assertions. I'm not sure if they belong in `DefineMultilineArgs`, or if 
`DefineSpacing` might be a better spot, or maybe a new test 
`DefineVerticalWhitespace`?



Comment at: clang/unittests/Lex/DependencyDirectivesSourceMinimizerTest.cpp:186
Out));
-  EXPECT_STREQ("#define MACRO(a)\n", Out.data());
-

Please don't remove this test coverage.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108742

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


[clang] a233f03 - Typo fix; NFC

2021-08-26 Thread Aaron Ballman via cfe-commits

Author: Aaron Ballman
Date: 2021-08-26T12:53:52-04:00
New Revision: a233f0350d4790227f138e2118c0d18c2b45f855

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

LOG: Typo fix; NFC

Added: 


Modified: 
clang/include/clang/AST/DeclTemplate.h

Removed: 




diff  --git a/clang/include/clang/AST/DeclTemplate.h 
b/clang/include/clang/AST/DeclTemplate.h
index cbaa287f225a5..d59a0549f4c10 100644
--- a/clang/include/clang/AST/DeclTemplate.h
+++ b/clang/include/clang/AST/DeclTemplate.h
@@ -1189,7 +1189,7 @@ class TemplateTypeParmDecl final : public TypeDecl,
 
   /// Whether the type constraint has been initialized. This can be false if 
the
   /// constraint was not initialized yet or if there was an error forming the
-  /// type constriant.
+  /// type constraint.
   bool TypeConstraintInitialized : 1;
 
   /// Whether this non-type template parameter is an "expanded"



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


[PATCH] D108765: [docs] Fix documentation of clang-format BasedOnStyle type

2021-08-26 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay added subscribers: HazardyKnusperkeks, owenpan, krasimir, 
sammccall, curdeius, klimek.
MyDeveloperDay added a comment.

In D108765#2967363 , @FederAndInk 
wrote:

> Thank you for your explanations, I understand now.
>
> But as I look into `clang/docs/tools/dump_format_style.py` I see that it does 
> not entirely generate `clang/docs/ClangFormatStyleOptions.rst` it replaces 
> the lines between `{START,END}_FORMAT_STYLE_OPTIONS`
>
> I understand your point, but as of now, the inconsistency comes from the part 
> that is not auto-generated, are you suggesting editing `dump_format_style.py` 
> to have simpler types such as `string`? Then how should we replace 
> `std::vector`? Something like `Type[]` e.g. `string[]`?
>
> Or maybe we should first include `BasedOnStyle` into `dump_format_style.py`. 
> Then take care of how to render types?
>
> What do you suggest? I am genuinely asking, as I really don't know what would 
> be the best way to do things. Maybe we should include other people? I don't 
> really know who to add as reviewers for that, but I think, the way to show 
> types, should be discussed?
>
> As for detailing `RawStringFormat`, it wasn't the purpose of this patch, and 
> maybe it should have its own?

You are correct the file isn't 100% generated and some of it comes from another 
.h file too.

But now we have you interesting in making a contribution which you clearly are 
lets think about how we might do this.

To hook into the clang-format team I always recommend adding the #clang-format 
 project, (which I added to this 
review), but also I recommend passing the review via @krasimir , 
@HazardyKnusperkeks , @curdeius there are some others who are hear often like 
@owenpan and @sammccall and of course @klimek (who started all this). Please 
also of course add me @MyDeveloperDay I try to check the reviews daily as one 
of my frustrations was not being able to get things reviewed so I try to be 
pretty active.

From my perspective I do like the idea of substituting out the `std::string` 
and `std::vector` for something like `string[]` how about we start with 
something simple like trying to fix the cases for `AttributeMacros 
(std::vector)` maybe with just simple substitution.

We can pass that via the rest of the team and see what they feel even if we 
ultimately have both

AttributeMacros (in configuration `string[]`)

or something like that, I'm not con convinced anyone is using this 
documentation to know its a std::vector!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108765

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


[PATCH] D108481: Avoid nullptr dereferencing of 'Constraint'

2021-08-26 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/lib/Sema/SemaConcept.cpp:1065-1068
   assert(TC &&
  "TPL must have a template type parameter with a type constraint");
   auto *Constraint =
+  cast(TC->getImmediatelyDeclaredConstraint());

erichkeane wrote:
> aaron.ballman wrote:
> > mlychkov wrote:
> > > aaron.ballman wrote:
> > > > If we're going to be touching this code, there's more suspect code here 
> > > > that needs to be cleaned up a bit. Directly above this is:
> > > > ```
> > > >   const TypeConstraint *TC =
> > > >   cast(TPL->getParam(0))->getTypeConstraint();
> > > >   assert(TC &&
> > > >  "TPL must have a template type parameter with a type 
> > > > constraint");
> > > > ```
> > > > That assertion can be removed entirely -- if the `cast<>` fails, it 
> > > > doesn't return null, it asserts.
> > > Actually, cast return nonnull value, but
> > >TC = "cast_result"->getTypeConstraint();
> > > and TC may become nullptr, I suppose.
> > Good catch! I think we should add the assertion on `TC` being nonnull back. 
> > I'll take care of that.
> Ooh, good catch!  I definitely missed that when suggesting removing the 
> assert.  @aaron.ballman  can you re-add the assert on 1065?
I've put the assert back in 0cf4f81082e9fa052e60450b8cbb10007e59931c, thanks 
for letting us know @mlychkov!


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

https://reviews.llvm.org/D108481

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


[clang] 0cf4f81 - Adding an assertion back.

2021-08-26 Thread Aaron Ballman via cfe-commits

Author: Aaron Ballman
Date: 2021-08-26T12:51:14-04:00
New Revision: 0cf4f81082e9fa052e60450b8cbb10007e59931c

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

LOG: Adding an assertion back.

This assert was removed in 98339f14a0420cdfbe4215d8d1bc0a01165e0495,
but during post-commit review, it was pointed out that the assert was
valid.

Added: 


Modified: 
clang/lib/Sema/SemaConcept.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaConcept.cpp b/clang/lib/Sema/SemaConcept.cpp
index c582446426892..2932335f3ad49 100644
--- a/clang/lib/Sema/SemaConcept.cpp
+++ b/clang/lib/Sema/SemaConcept.cpp
@@ -1062,6 +1062,8 @@ ReturnTypeRequirement(TemplateParameterList *TPL) :
   assert(TPL->size() == 1);
   const TypeConstraint *TC =
   cast(TPL->getParam(0))->getTypeConstraint();
+  assert(TC &&
+ "TPL must have a template type parameter with a type constraint");
   auto *Constraint =
   cast(TC->getImmediatelyDeclaredConstraint());
   bool Dependent =



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


[PATCH] D108624: [Clang][RISCV] Implement getConstraintRegister for RISC-V

2021-08-26 Thread Luís Marques via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG34e055d33e37: [Clang][RISCV] Implement getConstraintRegister 
for RISC-V (authored by luismarques).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108624

Files:
  clang/lib/Basic/Targets/RISCV.h
  clang/test/Sema/inline-asm-validate-riscv.c


Index: clang/test/Sema/inline-asm-validate-riscv.c
===
--- clang/test/Sema/inline-asm-validate-riscv.c
+++ clang/test/Sema/inline-asm-validate-riscv.c
@@ -21,3 +21,11 @@
   asm volatile ("" :: "K"(BelowMin)); // expected-error{{value '-1' out of 
range for constraint 'K'}}
   asm volatile ("" :: "K"(AboveMax)); // expected-error{{value '32' out of 
range for constraint 'K'}}
 }
+
+void test_clobber_conflict(void) {
+  register long x10 asm("x10");
+  asm volatile("" :: "r"(x10) : "x10"); // expected-error {{conflicts with asm 
clobber list}}
+  asm volatile("" :: "r"(x10) : "a0"); // expected-error {{conflicts with asm 
clobber list}}
+  asm volatile("" : "=r"(x10) :: "x10"); // expected-error {{conflicts with 
asm clobber list}}
+  asm volatile("" : "=r"(x10) :: "a0"); // expected-error {{conflicts with asm 
clobber list}}
+}
Index: clang/lib/Basic/Targets/RISCV.h
===
--- clang/lib/Basic/Targets/RISCV.h
+++ clang/lib/Basic/Targets/RISCV.h
@@ -82,6 +82,11 @@
 
   const char *getClobbers() const override { return ""; }
 
+  StringRef getConstraintRegister(StringRef Constraint,
+  StringRef Expression) const override {
+return Expression;
+  }
+
   ArrayRef getGCCRegNames() const override;
 
   int getEHDataRegisterNumber(unsigned RegNo) const override {


Index: clang/test/Sema/inline-asm-validate-riscv.c
===
--- clang/test/Sema/inline-asm-validate-riscv.c
+++ clang/test/Sema/inline-asm-validate-riscv.c
@@ -21,3 +21,11 @@
   asm volatile ("" :: "K"(BelowMin)); // expected-error{{value '-1' out of range for constraint 'K'}}
   asm volatile ("" :: "K"(AboveMax)); // expected-error{{value '32' out of range for constraint 'K'}}
 }
+
+void test_clobber_conflict(void) {
+  register long x10 asm("x10");
+  asm volatile("" :: "r"(x10) : "x10"); // expected-error {{conflicts with asm clobber list}}
+  asm volatile("" :: "r"(x10) : "a0"); // expected-error {{conflicts with asm clobber list}}
+  asm volatile("" : "=r"(x10) :: "x10"); // expected-error {{conflicts with asm clobber list}}
+  asm volatile("" : "=r"(x10) :: "a0"); // expected-error {{conflicts with asm clobber list}}
+}
Index: clang/lib/Basic/Targets/RISCV.h
===
--- clang/lib/Basic/Targets/RISCV.h
+++ clang/lib/Basic/Targets/RISCV.h
@@ -82,6 +82,11 @@
 
   const char *getClobbers() const override { return ""; }
 
+  StringRef getConstraintRegister(StringRef Constraint,
+  StringRef Expression) const override {
+return Expression;
+  }
+
   ArrayRef getGCCRegNames() const override;
 
   int getEHDataRegisterNumber(unsigned RegNo) const override {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 34e055d - [Clang][RISCV] Implement getConstraintRegister for RISC-V

2021-08-26 Thread Luís Marques via cfe-commits

Author: Luís Marques
Date: 2021-08-26T17:43:43+01:00
New Revision: 34e055d33e37cd87b9f6f4b0431a4c061628d036

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

LOG: [Clang][RISCV] Implement getConstraintRegister for RISC-V

The getConstraintRegister method is used by semantic checking of inline
assembly statements in order to diagnose conflicts between clobber list
and input/output lists. By overriding getConstraintRegister we get those
diagnostics and we match RISC-V GCC's behavior. The implementation is
trivial due to the lack of single-register RISC-V-specific constraints.

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

Added: 


Modified: 
clang/lib/Basic/Targets/RISCV.h
clang/test/Sema/inline-asm-validate-riscv.c

Removed: 




diff  --git a/clang/lib/Basic/Targets/RISCV.h b/clang/lib/Basic/Targets/RISCV.h
index 7e0846581ca1f..9609b6fc3f307 100644
--- a/clang/lib/Basic/Targets/RISCV.h
+++ b/clang/lib/Basic/Targets/RISCV.h
@@ -82,6 +82,11 @@ class RISCVTargetInfo : public TargetInfo {
 
   const char *getClobbers() const override { return ""; }
 
+  StringRef getConstraintRegister(StringRef Constraint,
+  StringRef Expression) const override {
+return Expression;
+  }
+
   ArrayRef getGCCRegNames() const override;
 
   int getEHDataRegisterNumber(unsigned RegNo) const override {

diff  --git a/clang/test/Sema/inline-asm-validate-riscv.c 
b/clang/test/Sema/inline-asm-validate-riscv.c
index 744f73e23cf26..43a5378bc3f25 100644
--- a/clang/test/Sema/inline-asm-validate-riscv.c
+++ b/clang/test/Sema/inline-asm-validate-riscv.c
@@ -21,3 +21,11 @@ void K(int k) {
   asm volatile ("" :: "K"(BelowMin)); // expected-error{{value '-1' out of 
range for constraint 'K'}}
   asm volatile ("" :: "K"(AboveMax)); // expected-error{{value '32' out of 
range for constraint 'K'}}
 }
+
+void test_clobber_conflict(void) {
+  register long x10 asm("x10");
+  asm volatile("" :: "r"(x10) : "x10"); // expected-error {{conflicts with asm 
clobber list}}
+  asm volatile("" :: "r"(x10) : "a0"); // expected-error {{conflicts with asm 
clobber list}}
+  asm volatile("" : "=r"(x10) :: "x10"); // expected-error {{conflicts with 
asm clobber list}}
+  asm volatile("" : "=r"(x10) :: "a0"); // expected-error {{conflicts with asm 
clobber list}}
+}



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


[PATCH] D108624: [Clang][RISCV] Implement getConstraintRegister for RISC-V

2021-08-26 Thread Alex Bradbury via Phabricator via cfe-commits
asb accepted this revision.
asb added a comment.
This revision is now accepted and ready to land.

Looks good to me - I'm surprised only Arm, AArch64, and X86 implement this!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108624

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


[PATCH] D107756: [analyzer] Extend the documentation of MallocOverflow

2021-08-26 Thread Balázs Benics via Phabricator via cfe-commits
steakhal added inline comments.



Comment at: clang/docs/analyzer/checkers.rst:2159-2160
+It tries to catch ``malloc(n * c)`` patterns, where:
+ - ``n``: a variable or member access of an object
+ - ``c``: a constant foldable integral
+

steakhal wrote:
> Am I supposed to indent this with 2 spaces? Or what.
It seems like an empty newline solved this before the list.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107756

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


[PATCH] D108481: Avoid nullptr dereferencing of 'Constraint'

2021-08-26 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added inline comments.



Comment at: clang/lib/Sema/SemaConcept.cpp:1065-1068
   assert(TC &&
  "TPL must have a template type parameter with a type constraint");
   auto *Constraint =
+  cast(TC->getImmediatelyDeclaredConstraint());

aaron.ballman wrote:
> mlychkov wrote:
> > aaron.ballman wrote:
> > > If we're going to be touching this code, there's more suspect code here 
> > > that needs to be cleaned up a bit. Directly above this is:
> > > ```
> > >   const TypeConstraint *TC =
> > >   cast(TPL->getParam(0))->getTypeConstraint();
> > >   assert(TC &&
> > >  "TPL must have a template type parameter with a type 
> > > constraint");
> > > ```
> > > That assertion can be removed entirely -- if the `cast<>` fails, it 
> > > doesn't return null, it asserts.
> > Actually, cast return nonnull value, but
> >TC = "cast_result"->getTypeConstraint();
> > and TC may become nullptr, I suppose.
> Good catch! I think we should add the assertion on `TC` being nonnull back. 
> I'll take care of that.
Ooh, good catch!  I definitely missed that when suggesting removing the assert. 
 @aaron.ballman  can you re-add the assert on 1065?


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

https://reviews.llvm.org/D108481

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


[PATCH] D108481: Avoid nullptr dereferencing of 'Constraint'

2021-08-26 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/lib/Sema/SemaConcept.cpp:1065-1068
   assert(TC &&
  "TPL must have a template type parameter with a type constraint");
   auto *Constraint =
+  cast(TC->getImmediatelyDeclaredConstraint());

mlychkov wrote:
> aaron.ballman wrote:
> > If we're going to be touching this code, there's more suspect code here 
> > that needs to be cleaned up a bit. Directly above this is:
> > ```
> >   const TypeConstraint *TC =
> >   cast(TPL->getParam(0))->getTypeConstraint();
> >   assert(TC &&
> >  "TPL must have a template type parameter with a type constraint");
> > ```
> > That assertion can be removed entirely -- if the `cast<>` fails, it doesn't 
> > return null, it asserts.
> Actually, cast return nonnull value, but
>TC = "cast_result"->getTypeConstraint();
> and TC may become nullptr, I suppose.
Good catch! I think we should add the assertion on `TC` being nonnull back. 
I'll take care of that.


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

https://reviews.llvm.org/D108481

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


[PATCH] D101960: [openmp] Drop requirement on library path environment variables

2021-08-26 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield added a comment.

Test setup can be fixed independently (and possibly should be).

D102043  is newly simplified. It looks for 
plugins next to libomptarget.so, which means it can find them even when the 
application uses a non-transitive method to find libomptarget.so.

Turns out libomptarget.so is linked directly to the application, not via 
libomp.so as I believed, and they're installed next to each other so whatever 
finds the first will find the second.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101960

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


[PATCH] D104285: [analyzer][AST] Retrieve value by direct index from list initialization of constant array declaration.

2021-08-26 Thread Denys Petrov via Phabricator via cfe-commits
ASDenysPetrov updated this revision to Diff 368905.
ASDenysPetrov edited the summary of this revision.
ASDenysPetrov added a comment.

Reworked the patch according to the discussion and taking UB into account. 
Moved `Expr::getExprForConstArrayByRawIndex` to `RegionStoreManager`.


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

https://reviews.llvm.org/D104285

Files:
  clang/include/clang/AST/Type.h
  clang/lib/AST/Type.cpp
  clang/lib/StaticAnalyzer/Core/RegionStore.cpp
  clang/test/Analysis/initialization.cpp

Index: clang/test/Analysis/initialization.cpp
===
--- clang/test/Analysis/initialization.cpp
+++ clang/test/Analysis/initialization.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -std=c++14 -triple i386-apple-darwin10 -analyze -analyzer-checker=core.builtin,debug.ExprInspection -verify %s
+// RUN: %clang_cc1 -std=c++14 -triple i386-apple-darwin10 -analyze -analyzer-checker=core.uninitialized.Assign,core.builtin,debug.ExprInspection,core.uninitialized.UndefReturn -verify %s
 
 void clang_analyzer_eval(int);
 
@@ -18,3 +18,106 @@
   // FIXME: Should recognize that it is 0.
   clang_analyzer_eval(arr[i][0]); // expected-warning{{UNKNOWN}}
 }
+
+int const glob_arr1[2][2][3] = {};
+void direct_index1() {
+  int const *ptr = (int const *)glob_arr1;
+  clang_analyzer_eval(ptr[0] == 0);  // expected-warning{{TRUE}}
+  clang_analyzer_eval(ptr[1] == 0);  // expected-warning{{TRUE}}
+  clang_analyzer_eval(ptr[2] == 0);  // expected-warning{{TRUE}}
+  clang_analyzer_eval(ptr[3] == 0);  // expected-warning{{UNDEFINED}}
+  clang_analyzer_eval(ptr[4] == 0);  // expected-warning{{UNDEFINED}}
+  clang_analyzer_eval(ptr[5] == 0);  // expected-warning{{UNDEFINED}}
+  clang_analyzer_eval(ptr[6] == 0);  // expected-warning{{UNDEFINED}}
+  clang_analyzer_eval(ptr[7] == 0);  // expected-warning{{UNDEFINED}}
+  clang_analyzer_eval(ptr[8] == 0);  // expected-warning{{UNDEFINED}}
+  clang_analyzer_eval(ptr[9] == 0);  // expected-warning{{UNDEFINED}}
+  clang_analyzer_eval(ptr[10] == 0); // expected-warning{{UNDEFINED}}
+  clang_analyzer_eval(ptr[11] == 0); // expected-warning{{UNDEFINED}}
+}
+
+int const glob_arr2[2][2][3] = {{{1, 2, 3}, {4, 5, 6}}, {{7, 8, 9}, {10, 11, 12}}};
+void direct_index2() {
+  int const *ptr = glob_arr2[0][0];
+  clang_analyzer_eval(ptr[0] == 1);   // expected-warning{{TRUE}}
+  clang_analyzer_eval(ptr[1] == 2);   // expected-warning{{TRUE}}
+  clang_analyzer_eval(ptr[2] == 3);   // expected-warning{{TRUE}}
+  clang_analyzer_eval(ptr[3] == 4);   // expected-warning{{UNDEFINED}}
+  clang_analyzer_eval(ptr[4] == 5);   // expected-warning{{UNDEFINED}}
+  clang_analyzer_eval(ptr[5] == 6);   // expected-warning{{UNDEFINED}}
+  clang_analyzer_eval(ptr[6] == 7);   // expected-warning{{UNDEFINED}}
+  clang_analyzer_eval(ptr[7] == 8);   // expected-warning{{UNDEFINED}}
+  clang_analyzer_eval(ptr[8] == 9);   // expected-warning{{UNDEFINED}}
+  clang_analyzer_eval(ptr[9] == 10);  // expected-warning{{UNDEFINED}}
+  clang_analyzer_eval(ptr[10] == 11); // expected-warning{{UNDEFINED}}
+  clang_analyzer_eval(ptr[11] == 12); // expected-warning{{UNDEFINED}}
+}
+
+int const glob_arr3[2][2][3] = {{{}, {}}, {{}, {}}};
+void direct_index3() {
+  int const *ptr = &(glob_arr3[0][0][0]);
+  clang_analyzer_eval(ptr[0] == 0);  // expected-warning{{TRUE}}
+  clang_analyzer_eval(ptr[1] == 0);  // expected-warning{{TRUE}}
+  clang_analyzer_eval(ptr[2] == 0);  // expected-warning{{TRUE}}
+  clang_analyzer_eval(ptr[3] == 0);  // expected-warning{{UNDEFINED}}
+  clang_analyzer_eval(ptr[4] == 0);  // expected-warning{{UNDEFINED}}
+  clang_analyzer_eval(ptr[5] == 0);  // expected-warning{{UNDEFINED}}
+  clang_analyzer_eval(ptr[6] == 0);  // expected-warning{{UNDEFINED}}
+  clang_analyzer_eval(ptr[7] == 0);  // expected-warning{{UNDEFINED}}
+  clang_analyzer_eval(ptr[8] == 0);  // expected-warning{{UNDEFINED}}
+  clang_analyzer_eval(ptr[9] == 0);  // expected-warning{{UNDEFINED}}
+  clang_analyzer_eval(ptr[10] == 0); // expected-warning{{UNDEFINED}}
+  clang_analyzer_eval(ptr[11] == 0); // expected-warning{{UNDEFINED}}
+}
+
+int const glob_arr4[2][2][3] = {{{1, 2}, {}}, {{7, 8}, {10, 11, 12}}};
+void direct_index4() {
+  int const *ptr = (int const *)glob_arr4[0];
+  clang_analyzer_eval(ptr[0] == 1);   // expected-warning{{TRUE}}
+  clang_analyzer_eval(ptr[1] == 2);   // expected-warning{{TRUE}}
+  clang_analyzer_eval(ptr[2] == 0);   // expected-warning{{TRUE}}
+  clang_analyzer_eval(ptr[3] == 0);   // expected-warning{{UNDEFINED}}
+  clang_analyzer_eval(ptr[4] == 0);   // expected-warning{{UNDEFINED}}
+  clang_analyzer_eval(ptr[5] == 0);   // expected-warning{{UNDEFINED}}
+  clang_analyzer_eval(ptr[6] == 7);   // expected-warning{{UNDEFINED}}
+  clang_analyzer_eval(ptr[7] == 8);   // expected-warning{{UNDEFINED}}
+  clang_analyzer_eval(ptr[8] == 0);   // expected-warning{{UNDEFINED}}
+  clang_analyzer_eval(ptr[9] == 10);  // 

[clang] af79f1b - [analyzer] Extend the documentation of MallocOverflow

2021-08-26 Thread Balazs Benics via cfe-commits

Author: Balazs Benics
Date: 2021-08-26T18:15:10+02:00
New Revision: af79f1bff90bee957ec9f963b68226e0b33eb169

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

LOG: [analyzer] Extend the documentation of MallocOverflow

Previously by following the documentation it was not immediately clear
what the capabilities of this checker are.

In this patch, I add some clarification on when does the checker issue a
report and what it's limitations are.
I'm also advertising suppressing such reports by adding an assertion, as
demonstrated by the test3().
I'm highlighting that this checker might produce an extensive amount of
findings, but it might be still useful for code audits.

Reviewed By: martong

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

Added: 


Modified: 
clang/docs/analyzer/checkers.rst

Removed: 




diff  --git a/clang/docs/analyzer/checkers.rst 
b/clang/docs/analyzer/checkers.rst
index 9a74dffc1658d..dc8698b8f0c8a 100644
--- a/clang/docs/analyzer/checkers.rst
+++ b/clang/docs/analyzer/checkers.rst
@@ -2154,7 +2154,15 @@ Warn about buffer overflows (newer checker).
 
 alpha.security.MallocOverflow (C)
 "
-Check for overflows in the arguments to malloc().
+Check for overflows in the arguments to ``malloc()``.
+It tries to catch ``malloc(n * c)`` patterns, where:
+
+ - ``n``: a variable or member access of an object
+ - ``c``: a constant foldable integral
+
+This checker was designed for code audits, so expect false-positive reports.
+One is supposed to silence this checker by ensuring proper bounds checking on
+the variable in question using e.g. an ``assert()`` or a branch.
 
 .. code-block:: c
 
@@ -2168,6 +2176,27 @@ Check for overflows in the arguments to malloc().
void *p = malloc(n * sizeof(int)); // no warning
  }
 
+ void test3(int n) {
+   assert(n <= 100 && "Contract violated.");
+   void *p = malloc(n * sizeof(int)); // no warning
+ }
+
+Limitations:
+
+ - The checker won't warn for variables involved in explicit casts,
+   since that might limit the variable's domain.
+   E.g.: ``(unsigned char)int x`` would limit the domain to ``[0,255]``.
+   The checker will miss the true-positive cases when the explicit cast would
+   not tighten the domain to prevent the overflow in the subsequent
+   multiplication operation.
+
+ - If the variable ``n`` participates in a comparison anywhere in the enclosing
+   function's scope, even after the ``malloc()``, the report will be still
+   suppressed.
+
+ - It is an AST-based checker, thus it does not make use of the
+   path-sensitive taint-analysis.
+
 .. _alpha-security-MmapWriteExec:
 
 alpha.security.MmapWriteExec (C)



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


[PATCH] D108481: Avoid nullptr dereferencing of 'Constraint'

2021-08-26 Thread Mikhail Lychkov via Phabricator via cfe-commits
mlychkov added inline comments.



Comment at: clang/lib/Sema/SemaConcept.cpp:1065-1068
   assert(TC &&
  "TPL must have a template type parameter with a type constraint");
   auto *Constraint =
+  cast(TC->getImmediatelyDeclaredConstraint());

aaron.ballman wrote:
> If we're going to be touching this code, there's more suspect code here that 
> needs to be cleaned up a bit. Directly above this is:
> ```
>   const TypeConstraint *TC =
>   cast(TPL->getParam(0))->getTypeConstraint();
>   assert(TC &&
>  "TPL must have a template type parameter with a type constraint");
> ```
> That assertion can be removed entirely -- if the `cast<>` fails, it doesn't 
> return null, it asserts.
Actually, cast return nonnull value, but
   TC = "cast_result"->getTypeConstraint();
and TC may become nullptr, I suppose.


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

https://reviews.llvm.org/D108481

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


[PATCH] D108377: [asan] Implemented flag to emit intrinsics to optimize ASan callbacks.

2021-08-26 Thread Kirill Stoimenov via Phabricator via cfe-commits
kstoimenov updated this revision to Diff 368903.
kstoimenov added a comment.

Added a test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108377

Files:
  llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
  llvm/test/Instrumentation/AddressSanitizer/asan-optimize-callbacks.ll

Index: llvm/test/Instrumentation/AddressSanitizer/asan-optimize-callbacks.ll
===
--- /dev/null
+++ llvm/test/Instrumentation/AddressSanitizer/asan-optimize-callbacks.ll
@@ -0,0 +1,86 @@
+; RUN: opt < %s -asan -enable-new-pm=0 -asan-instrumentation-with-call-threshold=0 \
+;  -asan-optimize-callbacks -S | FileCheck %s --check-prefixes=LOAD,STORE
+; RUN: opt < %s -asan -enable-new-pm=0 -asan-instrumentation-with-call-threshold=0 \
+;  -asan-optimize-callbacks --asan-kernel -S | \
+;  FileCheck %s --check-prefixes=LOAD-KERNEL,STORE-KERNEL
+
+target triple = "x86_64-unknown-linux-gnu"
+
+define void @load(i8* %p1, i16* %p2, i32* %p4, i64* %p8, i128* %p16)
+sanitize_address {
+  %n1 = load i8, i8* %p1, align 1
+  %n2 = load i16, i16* %p2, align 2
+  %n4 = load i32, i32* %p4, align 4
+  %n8 = load i64, i64* %p8, align 8
+  %n16 = load i128, i128* %p16, align 16
+; LOAD:  call void @llvm.asan.check.memaccess(i8* %p1, i32 0)
+; LOAD-NEXT: %n1 = load i8, i8* %p1, align 1
+; LOAD-NEXT: %1 = bitcast i16* %p2 to i8*
+; LOAD-NEXT: call void @llvm.asan.check.memaccess(i8* %1, i32 2)
+; LOAD-NEXT: %n2 = load i16, i16* %p2, align 2
+; LOAD-NEXT: %2 = bitcast i32* %p4 to i8*
+; LOAD-NEXT: call void @llvm.asan.check.memaccess(i8* %2, i32 4)
+; LOAD-NEXT: %n4 = load i32, i32* %p4, align 4
+; LOAD-NEXT: %3 = bitcast i64* %p8 to i8*
+; LOAD-NEXT: call void @llvm.asan.check.memaccess(i8* %3, i32 6)
+; LOAD-NEXT: %n8 = load i64, i64* %p8, align 8
+; LOAD-NEXT: %4 = bitcast i128* %p16 to i8*
+; LOAD-NEXT: call void @llvm.asan.check.memaccess(i8* %4, i32 8)
+; LOAD-NEXT: %n16 = load i128, i128* %p16, align 16
+
+; LOAD-KERNEL:  call void @llvm.asan.check.memaccess(i8* %p1, i32 1)
+; LOAD-KERNEL-NEXT: %n1 = load i8, i8* %p1, align 1
+; LOAD-KERNEL-NEXT: %1 = bitcast i16* %p2 to i8*
+; LOAD-KERNEL-NEXT: call void @llvm.asan.check.memaccess(i8* %1, i32 3)
+; LOAD-KERNEL-NEXT: %n2 = load i16, i16* %p2, align 2
+; LOAD-KERNEL-NEXT: %2 = bitcast i32* %p4 to i8*
+; LOAD-KERNEL-NEXT: call void @llvm.asan.check.memaccess(i8* %2, i32 5)
+; LOAD-KERNEL-NEXT: %n4 = load i32, i32* %p4, align 4
+; LOAD-KERNEL-NEXT: %3 = bitcast i64* %p8 to i8*
+; LOAD-KERNEL-NEXT: call void @llvm.asan.check.memaccess(i8* %3, i32 7)
+; LOAD-KERNEL-NEXT: %n8 = load i64, i64* %p8, align 8
+; LOAD-KERNEL-NEXT: %4 = bitcast i128* %p16 to i8*
+; LOAD-KERNEL-NEXT: call void @llvm.asan.check.memaccess(i8* %4, i32 9)
+; LOAD-KERNEL-NEXT: %n16 = load i128, i128* %p16, align 16
+  ret void
+}
+
+define void @store(i8* %p1, i16* %p2, i32* %p4, i64* %p8, i128* %p16)
+sanitize_address {
+  store i8 0, i8* %p1, align 1
+  store i16 0, i16* %p2, align 2
+  store i32 0, i32* %p4, align 4
+  store i64 0, i64* %p8, align 8
+  store i128 0, i128* %p16, align 16
+; STORE:  call void @llvm.asan.check.memaccess(i8* %p1, i32 32)
+; STORE-NEXT: store i8 0, i8* %p1, align 1
+; STORE-NEXT: %1 = bitcast i16* %p2 to i8*
+; STORE-NEXT: call void @llvm.asan.check.memaccess(i8* %1, i32 34)
+; STORE-NEXT: store i16 0, i16* %p2, align 2
+; STORE-NEXT: %2 = bitcast i32* %p4 to i8*
+; STORE-NEXT: call void @llvm.asan.check.memaccess(i8* %2, i32 36)
+; STORE-NEXT: store i32 0, i32* %p4, align 4
+; STORE-NEXT: %3 = bitcast i64* %p8 to i8*
+; STORE-NEXT: call void @llvm.asan.check.memaccess(i8* %3, i32 38)
+; STORE-NEXT: store i64 0, i64* %p8, align 8
+; STORE-NEXT: %4 = bitcast i128* %p16 to i8*
+; STORE-NEXT: call void @llvm.asan.check.memaccess(i8* %4, i32 40)
+; STORE-NEXT: store i128 0, i128* %p16, align 16
+
+; STORE-KERNEL:  call void @llvm.asan.check.memaccess(i8* %p1, i32 33)
+; STORE-KERNEL-NEXT: store i8 0, i8* %p1, align 1
+; STORE-KERNEL-NEXT: %1 = bitcast i16* %p2 to i8*
+; STORE-KERNEL-NEXT: call void @llvm.asan.check.memaccess(i8* %1, i32 35)
+; STORE-KERNEL-NEXT: store i16 0, i16* %p2, align 2
+; STORE-KERNEL-NEXT: %2 = bitcast i32* %p4 to i8*
+; STORE-KERNEL-NEXT: call void @llvm.asan.check.memaccess(i8* %2, i32 37)
+; STORE-KERNEL-NEXT: store i32 0, i32* %p4, align 4
+; STORE-KERNEL-NEXT: %3 = bitcast i64* %p8 to i8*
+; STORE-KERNEL-NEXT: call void @llvm.asan.check.memaccess(i8* %3, i32 39)
+; STORE-KERNEL-NEXT: store i64 0, i64* %p8, align 8
+; STORE-KERNEL-NEXT: %4 = bitcast i128* %p16 to i8*
+; STORE-KERNEL-NEXT: call void @llvm.asan.check.memaccess(i8* %4, i32 41)
+; STORE-KERNEL-NEXT: store i128 0, i128* %p16, align 16
+; STORE-KERNEL-NEXT: ret void
+  ret void
+}
Index: llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
===
--- 

[clang] 2de051b - [DebugInfo] convert btf_tag attrs to DI annotations for DISubprograms

2021-08-26 Thread Yonghong Song via cfe-commits

Author: Yonghong Song
Date: 2021-08-26T08:54:11-07:00
New Revision: 2de051ba124d92de953ac2420668407f458bcec6

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

LOG: [DebugInfo] convert btf_tag attrs to DI annotations for DISubprograms

Generate btf_tag annotations for DISubprograms. The annotations
are represented as an DINodeArray in DebugInfo.

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

Added: 
clang/test/CodeGen/attr-btf_tag-disubprogram-callsite.c
clang/test/CodeGen/attr-btf_tag-disubprogram.c

Modified: 
clang/lib/CodeGen/CGDebugInfo.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGDebugInfo.cpp 
b/clang/lib/CodeGen/CGDebugInfo.cpp
index 989945a1b4ff..57f915028dde 100644
--- a/clang/lib/CodeGen/CGDebugInfo.cpp
+++ b/clang/lib/CodeGen/CGDebugInfo.cpp
@@ -3951,10 +3951,13 @@ void CGDebugInfo::emitFunctionStart(GlobalDecl GD, 
SourceLocation Loc,
   unsigned ScopeLine = getLineNumber(ScopeLoc);
   llvm::DISubroutineType *DIFnType = getOrCreateFunctionType(D, FnType, Unit);
   llvm::DISubprogram *Decl = nullptr;
-  if (D)
+  llvm::DINodeArray Annotations = nullptr;
+  if (D) {
 Decl = isa(D)
? getObjCMethodDeclaration(D, DIFnType, LineNo, Flags, SPFlags)
: getFunctionDeclaration(D);
+Annotations = CollectBTFTagAnnotations(D);
+  }
 
   // FIXME: The function declaration we're constructing here is mostly reusing
   // declarations from CXXMethodDecl and not constructing new ones for 
arbitrary
@@ -3963,7 +3966,8 @@ void CGDebugInfo::emitFunctionStart(GlobalDecl GD, 
SourceLocation Loc,
   // are emitted as CU level entities by the backend.
   llvm::DISubprogram *SP = DBuilder.createFunction(
   FDContext, Name, LinkageName, Unit, LineNo, DIFnType, ScopeLine,
-  FlagsForDef, SPFlagsForDef, TParamsArray.get(), Decl);
+  FlagsForDef, SPFlagsForDef, TParamsArray.get(), Decl, nullptr,
+  Annotations);
   Fn->setSubprogram(SP);
   // We might get here with a VarDecl in the case we're generating
   // code for the initialization of globals. Do not record these decls
@@ -4022,10 +4026,11 @@ void CGDebugInfo::EmitFunctionDecl(GlobalDecl GD, 
SourceLocation Loc,
   if (CGM.getLangOpts().Optimize)
 SPFlags |= llvm::DISubprogram::SPFlagOptimized;
 
+  llvm::DINodeArray Annotations = CollectBTFTagAnnotations(D);
   llvm::DISubprogram *SP = DBuilder.createFunction(
   FDContext, Name, LinkageName, Unit, LineNo,
   getOrCreateFunctionType(D, FnType, Unit), ScopeLine, Flags, SPFlags,
-  TParamsArray.get(), getFunctionDeclaration(D));
+  TParamsArray.get(), getFunctionDeclaration(D), nullptr, Annotations);
 
   if (IsDeclForCallSite)
 Fn->setSubprogram(SP);

diff  --git a/clang/test/CodeGen/attr-btf_tag-disubprogram-callsite.c 
b/clang/test/CodeGen/attr-btf_tag-disubprogram-callsite.c
new file mode 100644
index ..fcba5dd6d8a1
--- /dev/null
+++ b/clang/test/CodeGen/attr-btf_tag-disubprogram-callsite.c
@@ -0,0 +1,19 @@
+// REQUIRES: x86-registered-target
+// RUN: %clang -target x86_64 -g -S -O2 -emit-llvm -o - %s | FileCheck %s
+
+#define __tag1 __attribute__((btf_tag("tag1")))
+#define __tag2 __attribute__((btf_tag("tag2")))
+
+struct t1 {
+  int a;
+};
+
+extern int __tag1 __tag2 foo(struct t1 *);
+int foo2(struct t1 *arg) {
+  return foo(arg);
+}
+
+// CHECK: ![[#]] = !DISubprogram(name: "foo", scope: ![[#]], file: ![[#]], 
line: [[#]], type: ![[#]], flags: DIFlagPrototyped, spFlags: DISPFlagOptimized, 
retainedNodes: ![[#]], annotations: ![[ANNOT:[0-9]+]])
+// CHECK: ![[ANNOT]] = !{![[TAG1:[0-9]+]], ![[TAG2:[0-9]+]]}
+// CHECK: ![[TAG1]] = !{!"btf_tag", !"tag1"}
+// CHECK: ![[TAG2]] = !{!"btf_tag", !"tag2"}

diff  --git a/clang/test/CodeGen/attr-btf_tag-disubprogram.c 
b/clang/test/CodeGen/attr-btf_tag-disubprogram.c
new file mode 100644
index ..4c22e690f8df
--- /dev/null
+++ b/clang/test/CodeGen/attr-btf_tag-disubprogram.c
@@ -0,0 +1,40 @@
+// REQUIRES: x86-registered-target
+// RUN: %clang -target x86_64 -g -S -emit-llvm -o - %s | FileCheck %s
+
+#define __tag1 __attribute__((btf_tag("tag1")))
+#define __tag2 __attribute__((btf_tag("tag2")))
+
+struct t1 {
+  int a;
+};
+
+int __tag1 __tag2 foo(struct t1 *arg) {
+  return arg->a;
+}
+
+// CHECK: distinct !DISubprogram(name: "foo", scope: ![[#]], file: ![[#]], 
line: [[#]], type: ![[#]], scopeLine: [[#]], flags: DIFlagPrototyped, spFlags: 
DISPFlagDefinition, unit: ![[#]], retainedNodes: ![[#]], annotations: 
![[ANNOT:[0-9]+]])
+// CHECK: ![[ANNOT]] = !{![[TAG1:[0-9]+]], ![[TAG2:[0-9]+]]}
+// CHECK: ![[TAG1]] = !{!"btf_tag", !"tag1"}
+// CHECK: ![[TAG2]] = !{!"btf_tag", !"tag2"}
+
+int __tag1 __tag2 foo2(struct t1 *arg);
+int foo2(struct t1 *arg) {
+  return arg->a;
+}
+
+// CHECK: distinct !DISubprogram(name: "foo2", 

[PATCH] D108302: [PowerPC] Fixed the crash due to early if conversion with fixed CR fields.

2021-08-26 Thread Amy Kwan via Phabricator via cfe-commits
amyk added a comment.

Please update the patch with full context.




Comment at: llvm/lib/Target/PowerPC/PPCInstrInfo.cpp:1546
+  // into a select.
+  if (Register::isPhysicalRegister(Cond[1].getReg())) {
+return false;

nit: `uses a physical register`



Comment at: llvm/test/CodeGen/PowerPC/ifcvt_cr_field.ll:3
+; RUN: llc < %s -mtriple=powerpc64-unknown-linux-gnu -mcpu=pwr7 
-verify-machineinstrs | FileCheck %s
+target datalayout = 
"E-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-f128:128:128-v128:128:128-n32:64"
+target triple = "powerpc64-unknown-linux-gnu"

Are the  `target datalayout` and `target triple` necessary?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108302

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


[PATCH] D107647: [PowerPC] MMA - Add __builtin_vsx_build_pair and __builtin_mma_build_acc builtins

2021-08-26 Thread Lei Huang via Phabricator via cfe-commits
lei added inline comments.



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:15833
+  // without the need for the programmer to swap operands.
+  if (IsLE) {
+SmallVector RevOps;

doesn't look like we need the interm var `IsLE`. Just use the call directly 
within the if stmt.
```
if (getTarget().isLittleEndian()) {
```



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:15835-15837
+unsigned NumVecs = 2;
+if (BuiltinID == PPC::BI__builtin_mma_build_acc)
+  NumVecs = 4;

```
unsigned NumVecs = (BuiltinID == PPC::BI__builtin_mma_build_acc) ? 4 : 2;



Comment at: clang/test/CodeGen/builtins-ppc-pair-mma.c:2
 // NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
 // RUN: %clang_cc1 -O3 -triple powerpc64le-unknown-unknown -target-cpu future 
-emit-llvm %s -o - | FileCheck %s
 

future -> pwr10
We need to add BE tests.



Comment at: clang/test/Sema/ppc-pair-mma-types.c:2
 // RUN: %clang_cc1 -triple powerpc64le-unknown-unknown -fsyntax-only \
 // RUN:   -target-cpu future %s -verify
 

this should be `-target-cpu pwer10` now.



Comment at: clang/test/Sema/ppc-pair-mma-types.c:2
 // RUN: %clang_cc1 -triple powerpc64le-unknown-unknown -fsyntax-only \
 // RUN:   -target-cpu future %s -verify
 

lei wrote:
> this should be `-target-cpu pwer10` now.
Please add BE testing.



Comment at: clang/test/Sema/ppc-pair-mma-types.c:265
+  __builtin_mma_xvf64ger(, vp3, vc);
+  *vpp = vp3;
+}

This looks like a dup of `testVPLocal()`.  Why not just add the new call line 
to that function right below the call to the deprecated function?




Comment at: clang/test/SemaCXX/ppc-pair-mma-types.cpp:2
 // RUN: %clang_cc1 -triple powerpc64le-unknown-unknown -fsyntax-only \
 // RUN:   -fcxx-exceptions -target-cpu future %s -verify
 

please update to pwr10


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107647

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


[PATCH] D108765: [docs] Fix documentation of clang-format BasedOnStyle type

2021-08-26 Thread Ludovic Jozeau via Phabricator via cfe-commits
FederAndInk added a comment.

Thank you for your explanations, I understand now.

But as I look into `clang/docs/tools/dump_format_style.py` I see that it does 
not entirely generate `clang/docs/ClangFormatStyleOptions.rst` it replaces the 
lines between `{START,END}_FORMAT_STYLE_OPTIONS`

I understand your point, but as of now, the inconsistency comes from the part 
that is not auto-generated, are you suggesting editing `dump_format_style.py` 
to have simpler types such as `string`? Then how should we replace 
`std::vector`? Something like `Type[]` e.g. `string[]`?

Or maybe we should first include `BasedOnStyle` into `dump_format_style.py`. 
Then take care of how to render types?

What do you suggest? I am genuinely asking, as I really don't know what would 
be the best way to do things. Maybe we should include other people? I don't 
really know who to add as reviewers for that, but I think, the way to show 
types, should be discussed?

As for detailing `RawStringFormat`, it wasn't the purpose of this patch, and 
maybe it should have its own?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108765

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


[PATCH] D101759: [PowerPC] Scalar IBM MASS library conversion pass

2021-08-26 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a reviewer: spatel.
lebedev.ri added a comment.

In D101759#2967331 , @masoud.ataei 
wrote:

> In D101759#2967250 , @lebedev.ri 
> wrote:
>
>> Do we *really* need `-enable-approx-func-fp-math`?
>> I'm pretty sure we are moving away from such global options, onto relying 
>> only on the per-instruction fast-math flags.
>
> I am handling LLVM intrinsic math functions in PPCISelLowering.cpp, so I need 
> to check for `TM.Options.ApproxFuncFPMath`. This is the only place that I 
> think I need it.

How is this going to work e.g. in LTO when not all TU's are compiled with 
fast-math flags?

I'm not familiar with those llc flags, but i'm quite sure that e.g. DAGCombiner
is transitioned away from using them, so i'm wary of adding new ones.

> Currently, I am updating `TM.Options.ApproxFuncFPMath` in 
> `llvm/lib/CodeGen/CommandFlags.cpp` using the global option. Please let me 
> know if there is a better way to update `TM.Options.ApproxFuncFPMath` based 
> on the local fast-math flag.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101759

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


[PATCH] D106618: [Clang][LLVM] generate btf_tag annotations for DISubprogram types

2021-08-26 Thread Yonghong Song via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGd383df32c0d5: [DebugInfo] generate btf_tag annotations for 
DISubprogram types (authored by yonghong-song).

Changed prior to commit:
  https://reviews.llvm.org/D106618?vs=368805=368891#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106618

Files:
  llvm/include/llvm/IR/DIBuilder.h
  llvm/include/llvm/IR/DebugInfoMetadata.h
  llvm/lib/AsmParser/LLParser.cpp
  llvm/lib/Bitcode/Reader/MetadataLoader.cpp
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/IR/AsmWriter.cpp
  llvm/lib/IR/DIBuilder.cpp
  llvm/lib/IR/DebugInfoMetadata.cpp
  llvm/lib/IR/LLVMContextImpl.h
  llvm/test/Bitcode/attr-btf_tag-disubprogram.ll

Index: llvm/test/Bitcode/attr-btf_tag-disubprogram.ll
===
--- /dev/null
+++ llvm/test/Bitcode/attr-btf_tag-disubprogram.ll
@@ -0,0 +1,46 @@
+; REQUIRES: x86-registered-target
+; RUN: llvm-as < %s | llvm-dis | FileCheck %s
+
+; Function Attrs: mustprogress nofree norecurse nosync nounwind readnone uwtable willreturn
+define dso_local i32 @f(i32 %a) local_unnamed_addr #0 !dbg !8 {
+entry:
+  call void @llvm.dbg.value(metadata i32 %a, metadata !13, metadata !DIExpression()), !dbg !17
+  ret i32 0, !dbg !18
+}
+
+; Function Attrs: nofree nosync nounwind readnone speculatable willreturn
+declare void @llvm.dbg.value(metadata, metadata, metadata) #1
+
+attributes #0 = { mustprogress nofree norecurse nosync nounwind readnone uwtable willreturn "frame-pointer"="none" "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" }
+attributes #1 = { nofree nosync nounwind readnone speculatable willreturn }
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!3, !4, !5, !6}
+!llvm.ident = !{!7}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, producer: "clang version 13.0.0 (https://github.com/llvm/llvm-project.git a6dd9d402a04d53403664bbb47771f2573c7ade0)", isOptimized: true, runtimeVersion: 0, emissionKind: FullDebug, enums: !2, splitDebugInlining: false, nameTableKind: None)
+!1 = !DIFile(filename: "func.c", directory: "/home/yhs/work/tests/llvm/btf_tag")
+!2 = !{}
+!3 = !{i32 7, !"Dwarf Version", i32 4}
+!4 = !{i32 2, !"Debug Info Version", i32 3}
+!5 = !{i32 1, !"wchar_size", i32 4}
+!6 = !{i32 7, !"uwtable", i32 1}
+!7 = !{!"clang version 13.0.0 (https://github.com/llvm/llvm-project.git a6dd9d402a04d53403664bbb47771f2573c7ade0)"}
+!8 = distinct !DISubprogram(name: "f", scope: !1, file: !1, line: 1, type: !9, scopeLine: 1, flags: DIFlagPrototyped | DIFlagAllCallsDescribed, spFlags: DISPFlagDefinition | DISPFlagOptimized, unit: !0, retainedNodes: !12, annotations: !14)
+!9 = !DISubroutineType(types: !10)
+!10 = !{!11, !11}
+!11 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!12 = !{!13}
+!13 = !DILocalVariable(name: "a", arg: 1, scope: !8, file: !1, line: 1, type: !11)
+!14 = !{!15, !16}
+!15 = !{!"btf_tag", !"a"}
+!16 = !{!"btf_tag", !"b"}
+
+; CHECK:distinct !DISubprogram(name: "f"
+; CHECK-SAME:   annotations: ![[ANNOT:[0-9]+]]
+; CHECK:![[ANNOT]] = !{![[TAG1:[0-9]+]], ![[TAG2:[0-9]+]]}
+; CHECK:![[TAG1]] = !{!"btf_tag", !"a"}
+; CHECK:![[TAG2]] = !{!"btf_tag", !"b"}
+
+!17 = !DILocation(line: 0, scope: !8)
+!18 = !DILocation(line: 1, column: 77, scope: !8)
Index: llvm/lib/IR/LLVMContextImpl.h
===
--- llvm/lib/IR/LLVMContextImpl.h
+++ llvm/lib/IR/LLVMContextImpl.h
@@ -696,6 +696,7 @@
   Metadata *Declaration;
   Metadata *RetainedNodes;
   Metadata *ThrownTypes;
+  Metadata *Annotations;
 
   MDNodeKeyImpl(Metadata *Scope, MDString *Name, MDString *LinkageName,
 Metadata *File, unsigned Line, Metadata *Type,
@@ -703,13 +704,14 @@
 unsigned VirtualIndex, int ThisAdjustment, unsigned Flags,
 unsigned SPFlags, Metadata *Unit, Metadata *TemplateParams,
 Metadata *Declaration, Metadata *RetainedNodes,
-Metadata *ThrownTypes)
+Metadata *ThrownTypes, Metadata *Annotations)
   : Scope(Scope), Name(Name), LinkageName(LinkageName), File(File),
 Line(Line), Type(Type), ScopeLine(ScopeLine),
 ContainingType(ContainingType), VirtualIndex(VirtualIndex),
 ThisAdjustment(ThisAdjustment), Flags(Flags), SPFlags(SPFlags),
 Unit(Unit), TemplateParams(TemplateParams), Declaration(Declaration),
-RetainedNodes(RetainedNodes), ThrownTypes(ThrownTypes) {}
+RetainedNodes(RetainedNodes), ThrownTypes(ThrownTypes),
+Annotations(Annotations) {}
   MDNodeKeyImpl(const DISubprogram *N)
   : Scope(N->getRawScope()), 

[PATCH] D101759: [PowerPC] Scalar IBM MASS library conversion pass

2021-08-26 Thread Masoud Ataei via Phabricator via cfe-commits
masoud.ataei marked an inline comment as done.
masoud.ataei added a comment.

In D101759#2967250 , @lebedev.ri 
wrote:

> Do we *really* need `-enable-approx-func-fp-math`?
> I'm pretty sure we are moving away from such global options, onto relying 
> only on the per-instruction fast-math flags.

I am handling LLVM intrinsic math functions in PPCISelLowering.cpp, so I need 
to check for `TM.Options.ApproxFuncFPMath`. This is the only place that I think 
I need it. 
Currently, I am updating `TM.Options.ApproxFuncFPMath` in 
`llvm/lib/CodeGen/CommandFlags.cpp` using the global option. Please let me know 
if there is a better way to update `TM.Options.ApproxFuncFPMath` based on the 
local fast-math flag.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101759

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


[PATCH] D106431: [clang-tidy] Fix cppcoreguidelines-init-variables by removing the enum FixIt, and add support for initialization check of scoped enum.

2021-08-26 Thread Whisperity via Phabricator via cfe-commits
whisperity added a comment.

@Sockke Sorry to circle back here, but it seems to me that Clang now has a flag 
`-Wuninitialized`. Could you check how it behaves, compared to this check? If 
there are overlaps, what should we do, @aaron.ballman? Should parts of the 
check be deprecated?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106431

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


[PATCH] D105269: [X86] AVX512FP16 instructions enabling 6/6

2021-08-26 Thread Pengfei Wang via Phabricator via cfe-commits
pengfei added inline comments.



Comment at: llvm/lib/Target/X86/X86InstrFoldTables.cpp:1852
+  { X86::VFCMULCPHZrr, X86::VFCMULCPHZrm, 0 },
+  { X86::VFCMULCSHZrr, X86::VFCMULCSHZrm, 
TB_NO_REVERSE },
   { X86::VFMADDPD4Yrr, X86::VFMADDPD4Ymr, 0 },

LuoYuanke wrote:
> Why FR32X version is not needed for complex scalar instructions?
Do you mean complex ss/sd? We don't have these instructions.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105269

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


[PATCH] D105269: [X86] AVX512FP16 instructions enabling 6/6

2021-08-26 Thread Pengfei Wang via Phabricator via cfe-commits
pengfei added inline comments.



Comment at: llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp:3902
+  case X86::VFCMADDCSHZr:
+  case X86::VFCMADDCSHZrb:
+  case X86::VFCMADDCSHZrbk:

LuoYuanke wrote:
> "b" means rounding. Right?
broadcasting



Comment at: llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp:3948
+for (unsigned i = 2; i < Inst.getNumOperands(); i++)
+  if (Inst.getOperand(i).isReg() && Dest == Inst.getOperand(i).getReg())
+return Warning(Ops[0]->getStartLoc(), "Destination register should be "

LuoYuanke wrote:
> Sorry, I didn't find the constrain in the spec.
#UD if (dest_reg == src1_reg) or ( dest_reg == src2_reg)



Comment at: llvm/lib/Target/X86/X86InstrAVX512.td:13640
+(v4f32 (OpNode VR128X:$src1, VR128X:$src2)),
+0, 0, 0, X86selects, "@earlyclobber $dst">, 
Sched<[sched.XMM]>;
+defm rm : AVX512_maskable I didn't see this flag for other scalar instructions, why we need it for 
> complex instruction?
Because all complex instructions have constrains "dst != src1 && dst != src2". 
We use earlyclobber to avoid the dst been assigned to src1 or src2.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105269

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


[PATCH] D108621: [HIPSPV] Add CUDA->SPIR-V address space mapping

2021-08-26 Thread Alexey Bader via Phabricator via cfe-commits
bader added inline comments.



Comment at: clang/lib/Basic/Targets/SPIR.h:59
+// translation). This mapping is enabled when the language mode is HIP.
+1, // cuda_device
+// cuda_constant pointer can be casted to default/"flat" pointer, but in

Anastasia wrote:
> I am slightly confused as in the LLVM project those address spaces are for 
> SPIR not SPIR-V though. It is however used outside of LLVM project by some 
> tools like SPIRV-LLVM Translator as a path to SPIR-V, but it has only been 
> done as a workaround since we had no SPIR-V support in the LLVM project yet. 
> And if we are adding it let's do it clean to avoid/resolve any confusion.
> 
> I think we need to keep both because some vendors do target/use SPIR but not 
> SPIR-V.
> 
> So if you are interested in SPIR-V and not SPIR you should probably add a new 
> target that will make things cleaner.
> I think we need to keep both because some vendors do target/use SPIR but not 
> SPIR-V.

@Anastasia, could you elaborate more on the difference between SPIR and SPIR-V?
I would like to understand what these terms mean in the context of LLVM project.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108621

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


[PATCH] D107764: [OpenMP][OpenMPIRBuilder] Implement loop unrolling.

2021-08-26 Thread Kiran Chandramohan via Phabricator via cfe-commits
kiranchandramohan added a comment.

I have a few minor questions.




Comment at: llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:2055
+/// Attach loop metadata \p Properties to the loop described by \p Loop. If the
+/// loop already has metadata, the loop properties are appended.
+static void addLoopMetadata(CanonicalLoopInfo *Loop,

Nit: In the body, it seems we are prepending.



Comment at: llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:2168-2169
+  // actually unrolls the loop.
+  UP.Threshold *= 1.5;
+  UP.PartialThreshold *= 1.5;
+

Should this be settable for experimentation or additional control? If not can 
you provide an explanation for these values?



Comment at: llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp:1666
 
+TEST_F(OpenMPIRBuilderTest, UnrollLoopFull) {
+  OpenMPIRBuilder OMPBuilder(*M);

Are we not calling ompbuilder finalize or verify because it is only adding 
metadata?



Comment at: llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp:1735
+
 TEST_F(OpenMPIRBuilderTest, StaticWorkShareLoop) {
   using InsertPointTy = OpenMPIRBuilder::InsertPointTy;

Should we add tests for workshare loops with unroll?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107764

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


[PATCH] D108765: [docs] Fix documentation of clang-format BasedOnStyle type

2021-08-26 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay requested changes to this revision.
MyDeveloperDay added a comment.
This revision now requires changes to proceed.

Thank you for your submission, but...

1. This is not the way to change this file, its autogenerated from 
clang/include/Format/Format.h using  clang/docs/tools/dump_format_style.py
2. Why do you think it should be std::string? To be honest this file pretty 
much describes the `YAML` file format of `.clang-format` so actually I would 
suggest it saying string was more correct

I think the main problem is options like this:

F18679590: image.png 

Here we say its a `std::vector` which doesn't really tell you 
much, as its actually just a `YAML` array of `RawStringFormat` records without 
actually telling you what a `RawStringFormat` record contains

  RawStringFormats:
- Language: TextProto
Delimiters:
  - 'pb'
  - 'proto'
EnclosingFunctions:
  - 'PARSE_TEXT_PROTO'
BasedOnStyle: google
- Language: Cpp
Delimiters:
  - 'cc'
  - 'cpp'
BasedOnStyle: llvm
CanonicalDelimiter: 'cc'

So whilst I see that you were being consistent I kind of feel its in the wrong 
direction, we should be moving away from using `C++` names here but more 
explaining what the `YAML` should look like.

Alas the C++ in Format.h is important because the types are needed because we 
are generating the documentation directly from the code. But in most of places 
we are using an enumeration like this one.

F18679643: image.png 

we are not saying  `clang::FormatStyle::RefernceAlignmentStyle` and I'm not 
convinced we'd want to

I hope that helps, but thank you for the patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108765

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


[PATCH] D107900: [clang-tidy] Add a new clang-tidy check for trivially copyable types passed by const reference

2021-08-26 Thread Julien Marrec via Phabricator via cfe-commits
jmarrec updated this revision to Diff 368881.
jmarrec added a comment.

documentation updates


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107900

Files:
  clang-tools-extra/clang-tidy/misc/CMakeLists.txt
  clang-tools-extra/clang-tidy/misc/MiscTidyModule.cpp
  clang-tools-extra/clang-tidy/misc/PodConstRefToValueCheck.cpp
  clang-tools-extra/clang-tidy/misc/PodConstRefToValueCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/docs/clang-tidy/checks/misc-pod-const-ref-to-value.rst
  clang-tools-extra/test/clang-tidy/checkers/misc-pod-const-ref-to-value.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/misc-pod-const-ref-to-value.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/misc-pod-const-ref-to-value.cpp
@@ -0,0 +1,75 @@
+// RUN: %check_clang_tidy %s misc-pod-const-ref-to-value %t
+
+int f1(const int );
+// CHECK-MESSAGES: :[[@LINE-1]]:8: warning: argument 'i' is a trivially copyable type and should not be passed by const-reference but by value [misc-pod-const-ref-to-value]
+// CHECK-FIXES: int f1(int i);
+int f2(const int , double d);
+// CHECK-MESSAGES: :[[@LINE-1]]:8: warning: argument 'i' is a trivially copyable type and should not be passed by const-reference but by value [misc-pod-const-ref-to-value]
+// CHECK-FIXES: int f2(int i, double d);
+
+int f3(double d, const int );
+// CHECK-MESSAGES: :[[@LINE-1]]:18: warning: argument 'i' is a trivially copyable type and should not be passed by const-reference but by value [misc-pod-const-ref-to-value]
+// CHECK-FIXES: int f3(double d, int i);
+
+int f4(const double , const double );
+// CHECK-MESSAGES: :[[@LINE-1]]:8: warning: argument 'd' is a trivially copyable type and should not be passed by const-reference but by value [misc-pod-const-ref-to-value]
+// CHECK-MESSAGES: :[[@LINE-2]]:25: warning: argument 'd2' is a trivially copyable type and should not be passed by const-reference but by value [misc-pod-const-ref-to-value]
+// CHECK-FIXES: int f4(double d, double d2);
+
+// clang-format off
+int f5(const int& i);
+// CHECK-MESSAGES: :[[@LINE-1]]:8: warning: argument 'i' is a trivially copyable type and should not be passed by const-reference but by value [misc-pod-const-ref-to-value]
+// CHECK-FIXES: int f5(int i);
+// clang-format on
+
+namespace n1 {
+class A {
+  static int g(const double );
+  // CHECK-MESSAGES: :[[@LINE-1]]:16: warning: argument 'd' is a trivially copyable type and should not be passed by const-reference but by value [misc-pod-const-ref-to-value]
+  // CHECK-FIXES: static int g(double d);
+};
+
+int A::g(const double ) {
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: argument 'd' is a trivially copyable type and should not be passed by const-reference but by value [misc-pod-const-ref-to-value]
+  // CHECK-FIXES: int A::g(double d) {
+  return static_cast(d);
+}
+} // namespace n1
+
+// Not triggering the check
+
+int f5(int i);
+int f6(int i, double d);
+int f7(int ); // Might be used for return...
+
+namespace n2 {
+class A {
+  static int g(double d);
+};
+
+int A::g(double d) {
+  return static_cast(d);
+}
+
+class B {
+  static int g(double );
+};
+
+int B::g(double ) {
+  return static_cast(d);
+}
+} // namespace n2
+
+template 
+void f(Args &&...args);
+
+struct Widget {
+  int a[1000];
+};
+void f(const Widget &);
+
+template 
+struct Max {
+  static T max(const T , const T );
+};
+int x = Max::max(1, 2); // passes `int` by const reference, but this is fine
Index: clang-tools-extra/docs/clang-tidy/checks/misc-pod-const-ref-to-value.rst
===
--- /dev/null
+++ clang-tools-extra/docs/clang-tidy/checks/misc-pod-const-ref-to-value.rst
@@ -0,0 +1,25 @@
+.. title:: clang-tidy - misc-pod-const-ref-to-value
+
+misc-pod-const-ref-to-value
+===
+
+This check detects when ``trivially_copyable`` types are passed by const-reference
+to a function and changes that to by value/
+
+For example in the following code, it is replaced by ``void f(int i, double d)``:
+
+.. code-block:: c++
+
+  void f(const int& i, const double& d);
+
+
+Options
+---
+
+.. option:: RestrictToBuiltInTypes
+
+   If set to `true`, this check will limit itself to the `builtinType()` types. Default is `false`.
+
+.. option:: MaxSize
+
+   MaxSize: int, default 16. Above this size, passing by const-reference makes sense
Index: clang-tools-extra/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -215,6 +215,7 @@
`misc-no-recursion `_,
`misc-non-copyable-objects `_,
`misc-non-private-member-variables-in-classes `_,
+   `misc-pod-const-ref-to-value `_, "Yes"

[PATCH] D108138: [SimplifyCFG] Remove switch statements before vectorization

2021-08-26 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 added a comment.

>> I had a look at the LowerSwitch pass as suggested by @junparser, and I did 
>> find that running it before vectorisation transforms the switch and allows 
>> the same loops to be vectorised. However, I did find that if the loop is not 
>> vectorised then the switch is not created again later by SimplifyCFG

Maybe always lower switch in loops before LV?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108138

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


[PATCH] D101759: [PowerPC] Scalar IBM MASS library conversion pass

2021-08-26 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

Do we *really* need `-enable-approx-func-fp-math`?
I'm pretty sure we are moving away from such global options, onto relying only 
on the per-instruction fast-math flags.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101759

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


[PATCH] D108138: [SimplifyCFG] Remove switch statements before vectorization

2021-08-26 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 added a comment.

>> I could try to change LowerSwitch to create branches which SimplifyCFG will 
>> be able to recognise and replace with a switch, or try to change SimplifyCFG 
>> to recognise this pattern of compares & branches.



2. option is better.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108138

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


  1   2   >