[PATCH] D86373: [analyzer] Add modeling for unique_ptr move constructor

2020-08-21 Thread Nithin VR via Phabricator via cfe-commits
vrnithinkumar added inline comments. Comment at: clang/test/Analysis/smart-ptr.cpp:295 + P->foo(); // No warning. +} I was trying to test the below code. ``` void foo_() { std::unique_ptr PToMove; std::unique_ptr&& AfterRValeRefCast = std::move(functionRet

[PATCH] D85998: Add clang-cl "vctoolsdir" option to specify the location of the msvc toolchain

2020-08-21 Thread Alexandre Ganea via Phabricator via cfe-commits
aganea added subscribers: amccarth, dblaikie. aganea added a comment. In D85998#2231001 , @zahen wrote: > The build system strives to be deterministic When you say build system, you mean MSBuild? Other? For example, Fastbuild purposely calls `CreateProce

[PATCH] D86218: Teach the swift calling convention about _Atomic types

2020-08-21 Thread John McCall via Phabricator via cfe-commits
rjmccall accepted this revision. rjmccall added a comment. This revision is now accepted and ready to land. Thanks, LGTM. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86218/new/ https://reviews.llvm.org/D86218

[PATCH] D85998: Add clang-cl "vctoolsdir" option to specify the location of the msvc toolchain

2020-08-21 Thread Zachary Henkel via Phabricator via cfe-commits
zahen added a comment. We use BuildXL. Thanks for the comments. I'll make the requested changes and get a new rev posted. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D85998/new/ https://reviews.llvm.org/D85998 ___ cfe-commits mailing list

[PATCH] D86376: [HIP] Improve kernel launching latency

2020-08-21 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl created this revision. yaxunl added reviewers: tra, rjmccall. yaxunl requested review of this revision. Currently clang emits emits the following code for triple chevron kernel call for HIP: __hipPushCallConfiguration(grids, blocks, shmem, stream); kernel_stub(); whereas for each ker

[PATCH] D86310: [X86] Align i128 to 16 bytes in x86-64 datalayout

2020-08-21 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added a comment. As far as I know, there are basically three categories of things that depend on the alignment of a type. 1. The default alignment of load/store/alloca. On trunk, load/store/alloca always have explicitly specified alignment in memory. That said, old bitcode doesn't h

[PATCH] D85998: Add clang-cl "vctoolsdir" option to specify the location of the msvc toolchain

2020-08-21 Thread Alexandre Ganea via Phabricator via cfe-commits
aganea added inline comments. Comment at: clang/test/Driver/cl-options.c:685 +// vctoolsdir is handled by the driver; just check that we don't error. Pass -c because fakedir isn't a real toolchain path +// RUN: %clang_cl -c -vctoolsdir fakedir -- %s 2>&1 One m

[PATCH] D81703: [Clang] Don't leave Expr::Classification fields uninitialized in default constructor

2020-08-21 Thread Vitaly Buka via Phabricator via cfe-commits
vitalybuka added a comment. Compiler warning should already catch this Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D81703/new/ https://reviews.llvm.org/D81703 ___ cfe-commits mailing list cfe-commits@li

[PATCH] D86373: [analyzer] Add modeling for unique_ptr move constructor

2020-08-21 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added a comment. This is easier than D86293 because there's no old value in the freshly constructed smart pointer, right? I suspect that you can still re-use a lot of the implementation with D86293 , at least partially. =

[PATCH] D86293: [analyzer] Add modeling of Eq operator in smart ptr

2020-08-21 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added a comment. This looks outright correct to me. I have random suggestions on note text here and there. Comment at: clang/test/Analysis/smart-ptr-text-output.cpp:132 + std::unique_ptr PToMove; // expected-note {{Default constructed smart pointer 'PToMove' is null}} +

[PATCH] D83500: [PowerPC][Power10] Implement custom codegen for the vec_replace_elt and vec_replace_unaligned builtins.

2020-08-21 Thread Amy Kwan via Phabricator via cfe-commits
amyk updated this revision to Diff 287142. amyk added a comment. Address review comments: - Further consolidate the custom codegen of the two builtins - Add SemaChecking for if the third argument is a constant, if the third argument is in range and if the second argument is the same type as the

[PATCH] D86156: [BFI] Preserve BFI information through loop passes via VH callbacks inside LoopStandardAnalysisResults

2020-08-21 Thread Di Mo via Phabricator via cfe-commits
modimo updated this revision to Diff 287152. modimo added a comment. Herald added subscribers: lxfind, nikic. @asbirlea Thanks for taking a look! I updated BFI to resemble MSSA as recommended which removed the BFI calculation unless LICM is invoked. Also removed the spurious diffs from formattin

[PATCH] D86156: [BFI] Preserve BFI information through loop passes via VH callbacks inside LoopStandardAnalysisResults

2020-08-21 Thread Di Mo via Phabricator via cfe-commits
modimo added inline comments. Comment at: llvm/include/llvm/Transforms/Scalar/LoopPassManager.h:408 FunctionToLoopPassAdaptor createFunctionToLoopPassAdaptor(LoopPassT Pass, bool UseMemorySSA = false, +bool UseBlockFrequencyInfo = false,

[PATCH] D86156: [BFI] Preserve BFI information through loop passes via VH callbacks inside LoopStandardAnalysisResults

2020-08-21 Thread Nikita Popov via Phabricator via cfe-commits
nikic requested changes to this revision. nikic added a comment. This revision now requires changes to proceed. This change adds three PDT calculations to the standard pipeline. Please try to avoid the PDT calculations if PGO is not used, possibly by using LazyBPI. CHANGES SINCE LAST ACTION h

[PATCH] D86295: [analyzer] Reorder the layout of MemRegion and cache by hand for optimal size

2020-08-21 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added a comment. In D86295#2230603 , @steakhal wrote: > In D86295#2229712 , @NoQ wrote: > >> Heh, nice! Did you try to measure the actual impact of this change on memory >> and/or performance? > > Eh, I don't r

<    1   2