r312468 - [analyzer] Increase minimum complexity filter of the CloneChecker.

Author: teemperor Date: Sun Sep 3 22:56:36 2017 New Revision: 312468 URL: http://llvm.org/viewvc/llvm-project?rev=312468=rev Log: [analyzer] Increase minimum complexity filter of the CloneChecker. Summary: So far we used a value of 10 which was useful for testing but produces many

[PATCH] D34178: [analyzer] Increase minimum complexity filter of the CloneChecker.

This revision was automatically updated to reflect the committed changes. Closed by commit rL312468: [analyzer] Increase minimum complexity filter of the CloneChecker. (authored by teemperor). Changed prior to commit: https://reviews.llvm.org/D34178?vs=113725=113726#toc Repository: rL LLVM

[PATCH] D34178: [analyzer] Increase minimum complexity filter of the CloneChecker.

teemperor updated this revision to Diff 113725. teemperor added a comment. - Rebased and updated patch before merging. https://reviews.llvm.org/D34178 Files: lib/StaticAnalyzer/Checkers/CloneChecker.cpp test/Analysis/copypaste/asm.cpp test/Analysis/copypaste/attributes.cpp

Re: [PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type

On 09/03/2017 11:22 PM, Wei Mi wrote: On Sun, Sep 3, 2017 at 8:55 PM, Hal Finkel wrote: On 09/03/2017 10:38 PM, Xinliang David Li wrote: Store forwarding stall cost is usually much higher compared with a load hitting L1 cache. For instance, on Haswell, the latter is ~4

Re: [PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type

On 09/04/2017 12:12 AM, Xinliang David Li wrote: On Sun, Sep 3, 2017 at 9:23 PM, Hal Finkel > wrote: On 09/03/2017 11:06 PM, Xinliang David Li wrote: I think we can think this in another way. For modern CPU architectures which

r312467 - Implement Itanium name mangling support for C++ Modules TS.

Author: rsmith Date: Sun Sep 3 22:37:53 2017 New Revision: 312467 URL: http://llvm.org/viewvc/llvm-project?rev=312467=rev Log: Implement Itanium name mangling support for C++ Modules TS. This follows the scheme agreed with Nathan Sidwell, which can be found here:

[PATCH] D37433: [cxx_status] Mark coroutine TS support as clang 5.0 and change class from svn to full for P0096R4

GorNishanov created this revision. Shall we? https://reviews.llvm.org/D37433 Files: www/cxx_status.html Index: www/cxx_status.html === --- www/cxx_status.html +++ www/cxx_status.html @@ -872,7 +872,7 @@ -

Re: [PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type

On Sun, Sep 3, 2017 at 9:23 PM, Hal Finkel wrote: > > On 09/03/2017 11:06 PM, Xinliang David Li wrote: > > I think we can think this in another way. > > For modern CPU architectures which supports store forwarding with store > queues, it is generally not "safe" to blindly do

Re: [PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type

On 09/03/2017 11:06 PM, Xinliang David Li wrote: I think we can think this in another way. For modern CPU architectures which supports store forwarding with store queues, it is generally not "safe" to blindly do local optimizations to widen the load/stores Why not widen stores? Generally

Re: [PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type

On Sun, Sep 3, 2017 at 8:55 PM, Hal Finkel wrote: > > On 09/03/2017 10:38 PM, Xinliang David Li wrote: > > Store forwarding stall cost is usually much higher compared with a load > hitting L1 cache. For instance, on Haswell, the latter is ~4 cycles, while > the store forwarding

[PATCH] D37400: [StaticAnalyzer] Fix failures due to the iteration order of ExplodedNode

mgrang updated this revision to Diff 113720. mgrang added a comment. I had accidentally pushed a wrong patch to this commit. Fixed it now. https://reviews.llvm.org/D37400 Files: include/clang/StaticAnalyzer/Core/PathSensitive/ExplodedGraph.h Index:

[PATCH] D37400: [StaticAnalyzer] Fix failures due to the iteration order of ExplodedNode

mgrang updated this revision to Diff 113718. mgrang added a comment. NFC. Made the static_assert the first statement in the test. Repository: rL LLVM https://reviews.llvm.org/D37400 Files: unittests/Support/ReverseIterationTest.cpp Index: unittests/Support/ReverseIterationTest.cpp

Re: [PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type

I think we can think this in another way. For modern CPU architectures which supports store forwarding with store queues, it is generally not "safe" to blindly do local optimizations to widen the load/stores without sophisticated inter-procedural analysis. Doing so will run the risk of greatly

Re: [PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type

On 09/03/2017 10:38 PM, Xinliang David Li wrote: Store forwarding stall cost is usually much higher compared with a load hitting L1 cache. For instance, on Haswell, the latter is ~4 cycles, while the store forwarding stalls cost about 10 cycles more than a successful store forwarding, which

Re: [PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type

Store forwarding stall cost is usually much higher compared with a load hitting L1 cache. For instance, on Haswell, the latter is ~4 cycles, while the store forwarding stalls cost about 10 cycles more than a successful store forwarding, which is roughly 15 cycles. In some scenarios, the store

Re: [PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type

On 09/03/2017 03:44 PM, Wei Mi wrote: On Sat, Sep 2, 2017 at 6:04 PM, Hal Finkel wrote: On 08/22/2017 10:56 PM, Wei Mi via llvm-commits wrote: On Tue, Aug 22, 2017 at 7:03 PM, Xinliang David Li wrote: On Tue, Aug 22, 2017 at 6:37 PM, Chandler Carruth

Re: [PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type

On Sat, Sep 2, 2017 at 6:04 PM, Hal Finkel wrote: > > On 08/22/2017 10:56 PM, Wei Mi via llvm-commits wrote: >> >> On Tue, Aug 22, 2017 at 7:03 PM, Xinliang David Li >> wrote: >>> >>> >>> On Tue, Aug 22, 2017 at 6:37 PM, Chandler Carruth via Phabricator >>>

[PATCH] D37428: Debug info: Fixed faulty debug locations for attributed statements

Ka-Ka added inline comments. Comment at: test/CodeGen/debug-info-attributed-stmt.c:18 +// CHECK: br label %while.cond, !dbg ![[NUM]], !llvm.loop +// CHECK: ![[NUM]] = !DILocation(line: 9, scope: !14) +} The part "scope: !14)" should be removed from the testcase.

[PATCH] D37428: Debug info: Fixed faulty debug locations for attributed statements

Ka-Ka created this revision. Herald added a subscriber: aprantl. As no stoppoint was generated the attributed statements got faulty debug locations. https://reviews.llvm.org/D37428 Files: lib/CodeGen/CGStmt.cpp test/CodeGen/debug-info-attributed-stmt.c Index:

r312447 - [CodeGen] Treat all vector fields as mayalias

Author: hfinkel Date: Sun Sep 3 10:18:25 2017 New Revision: 312447 URL: http://llvm.org/viewvc/llvm-project?rev=312447=rev Log: [CodeGen] Treat all vector fields as mayalias Because it is common to treat vector types as an array of their elements, or even some other type that's not the element

r312444 - Test commit access in clang.

Author: jbhateja Date: Sun Sep 3 08:29:38 2017 New Revision: 312444 URL: http://llvm.org/viewvc/llvm-project?rev=312444=rev Log: Test commit access in clang. Differential Revision: https://reviews.llvm.org/D37426 Modified: cfe/trunk/README.txt Modified: cfe/trunk/README.txt URL:

[PATCH] D37207: [libc++] Add MINGW_LIBRARIES to the linker flags

mstorsjo added a comment. Ping https://reviews.llvm.org/D37207 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D37134: [libc++] Rerun ranlib manually after merging the static libraries

mstorsjo added a comment. Ping https://reviews.llvm.org/D37134 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D37133: [libc++] Handle object files named *.obj in merge_archives.py

mstorsjo added a comment. Ping https://reviews.llvm.org/D37133 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D36678: [OpenCL] Do not use vararg in emitted functions for enqueue_kernel

This revision was automatically updated to reflect the committed changes. Closed by commit rL312441: [OpenCL] Do not use vararg in emitted functions for enqueue_kernel (authored by yaxunl). Changed prior to commit: https://reviews.llvm.org/D36678?vs=113483=113694#toc Repository: rL LLVM

r312441 - [OpenCL] Do not use vararg in emitted functions for enqueue_kernel

Author: yaxunl Date: Sun Sep 3 06:52:24 2017 New Revision: 312441 URL: http://llvm.org/viewvc/llvm-project?rev=312441=rev Log: [OpenCL] Do not use vararg in emitted functions for enqueue_kernel Not all targets support vararg (e.g. amdgpu). Instead of using vararg in the emitted functions for

[PATCH] D34361: [analyzer] MinComplexityConstraint now early exits and only does one macro stack lookup

This revision was automatically updated to reflect the committed changes. Closed by commit rL312440: [analyzer] MinComplexityConstraint now early exits and only does one macro… (authored by teemperor). Changed prior to commit: https://reviews.llvm.org/D34361?vs=113692=113693#toc Repository:

r312440 - [analyzer] MinComplexityConstraint now early exits and only does one macro stack lookup

Author: teemperor Date: Sun Sep 3 06:45:33 2017 New Revision: 312440 URL: http://llvm.org/viewvc/llvm-project?rev=312440=rev Log: [analyzer] MinComplexityConstraint now early exits and only does one macro stack lookup Summary: This patch contains performance improvements for the

[PATCH] D34361: [analyzer] MinComplexityConstraint now early exits and only does one macro stack lookup

teemperor updated this revision to Diff 113692. teemperor added a comment. - Rebased and fixed merge conflicts before merging. https://reviews.llvm.org/D34361 Files: include/clang/Analysis/CloneDetection.h lib/Analysis/CloneDetection.cpp Index: lib/Analysis/CloneDetection.cpp

[PATCH] D35775: [x86][inline-asm]Extend support for memory reference expression

coby abandoned this revision. coby added a comment. superseded by https://reviews.llvm.org/D37412 Repository: rL LLVM https://reviews.llvm.org/D35775 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

r312437 - clang-format: Fix formatting of for loops with multiple increments.

Author: djasper Date: Sun Sep 3 01:56:24 2017 New Revision: 312437 URL: http://llvm.org/viewvc/llvm-project?rev=312437=rev Log: clang-format: Fix formatting of for loops with multiple increments. This fixes llvm.org/PR34366. Modified: cfe/trunk/lib/Format/TokenAnnotator.cpp