Re: r301815 - Adapt to LLVM's rename of WeakVH to WeakTrackingVH; NFC

Hi Yaron, On Wed, May 3, 2017 at 2:11 AM, Yaron Keren wrote: > out-of-tree code that uses WeakVH will continue to compile OK but may not > perform OK with WeakVH not tracking anymore. > May be better not to reuse WeakVH yet so such code will fail compilation. Typically we tend to focus on simpli

r301815 - Adapt to LLVM's rename of WeakVH to WeakTrackingVH; NFC

Author: sanjoy Date: Mon May 1 12:08:00 2017 New Revision: 301815 URL: http://llvm.org/viewvc/llvm-project?rev=301815&view=rev Log: Adapt to LLVM's rename of WeakVH to WeakTrackingVH; NFC Modified: cfe/trunk/lib/CodeGen/CGDeclCXX.cpp cfe/trunk/lib/CodeGen/CGObjCMac.cpp cfe/trunk/lib/

r301789 - Remove unneeded struct; NFC

Author: sanjoy Date: Mon May 1 01:12:13 2017 New Revision: 301789 URL: http://llvm.org/viewvc/llvm-project?rev=301789&view=rev Log: Remove unneeded struct; NFC Summary: Unless I'm missing something, the DeferredGlobal struct's GV field is unused, removing which makes the struct itself trivial.

r301430 - Revert "Update to LLVM's use of WeakTrackingVH; NFC"

Author: sanjoy Date: Wed Apr 26 11:37:51 2017 New Revision: 301430 URL: http://llvm.org/viewvc/llvm-project?rev=301430&view=rev Log: Revert "Update to LLVM's use of WeakTrackingVH; NFC" This reverts commit r301427. Modified: cfe/trunk/lib/CodeGen/CGDeclCXX.cpp cfe/trunk/lib/CodeGen/CGObj

r301427 - Update to LLVM's use of WeakTrackingVH; NFC

Author: sanjoy Date: Wed Apr 26 11:22:36 2017 New Revision: 301427 URL: http://llvm.org/viewvc/llvm-project?rev=301427&view=rev Log: Update to LLVM's use of WeakTrackingVH; NFC Summary: Depends on D32266 Reviewers: davide, dblaikie Subscribers: mcrosier, llvm-commits Differential Revision: htt

Re: [llvm-dev] Upgrading phabricator

It looks like the new phabricator sends html email by default. I personally prefer text email. What do others think? Is this configurable in the new installation? Thanks, -- Sanjoy Zachary Turner via llvm-commits wrote: You mentioned this was for an upgrade. Are there any major new features

Re: [PATCH] D21773: [clang] Update an optimization remark test for change D18777

sanjoy added a subscriber: anemet. sanjoy added a comment. Sound plausible, but I don't know this area (optimization remarks) well enough to sign off on this. @anemet can you please take a look? http://reviews.llvm.org/D21773 ___ cfe-commits maili

Re: [PATCH] D21507: Changes after running check modernize-use-emplace (D20964)

sanjoy added a comment. One other thing to point out -- have you verified that the changes in `unittests/` are benign (i.e. you're not semantically changing the tests)? Repository: rL LLVM http://reviews.llvm.org/D21507 ___ cfe-commits mailing l

r265767 - Adapt to LLVM API change

Author: sanjoy Date: Thu Apr 7 20:31:02 2016 New Revision: 265767 URL: http://llvm.org/viewvc/llvm-project?rev=265767&view=rev Log: Adapt to LLVM API change Replace mayBeOverridden with isInterposable Modified: cfe/trunk/lib/CodeGen/CodeGenFunction.cpp cfe/trunk/lib/CodeGen/CodeGenModul

Re: [PATCH] D15998: Implement __attribute__((gc_leaf_function)).

sanjoy resigned from this revision. sanjoy removed a reviewer: sanjoy. sanjoy added a comment. Resigning for now to make my "Revisions Waiting on You" queue less noisy. Please don't hesitate to add me back if this or a variant of this change becomes active. http://reviews.llvm.org/D15998 _

Re: [PATCH] D8899: [CodeGen] Annotate signed shift lefts with NUW

sanjoy resigned from this revision. sanjoy removed a reviewer: sanjoy. sanjoy added a comment. This revision hasn't changed for a while, removing myself from reviewers so that it does not show up in my 'waiting on others' list. Feel free to re-add my as a reviewer later if needed. http://revie

r248632 - Change arc-cxx11-init-list.mm to work with upcoming SCEV changes.

Author: sanjoy Date: Fri Sep 25 18:07:11 2015 New Revision: 248632 URL: http://llvm.org/viewvc/llvm-project?rev=248632&view=rev Log: Change arc-cxx11-init-list.mm to work with upcoming SCEV changes. Summary: The store being checked for in arc-cxx11-init-list.mm is a store to an unescaped alloca.

[PATCH] D13183: Change arc-cxx11-init-list.mm to work with upcoming SCEV changes.

sanjoy created this revision. sanjoy added a reviewer: compnerd. sanjoy added a subscriber: cfe-commits. The store being checked for in arc-cxx11-init-list.mm is a store to an unescaped alloca. After an uncoming change to ScalarEvolution, LLVM is able to elide the store, so adjust the test accord

Re: [PATCH] D13183: Change arc-cxx11-init-list.mm to work with upcoming SCEV changes.

This revision was automatically updated to reflect the committed changes. Closed by commit rL248632: Change arc-cxx11-init-list.mm to work with upcoming SCEV changes. (authored by sanjoy). Changed prior to commit: http://reviews.llvm.org/D13183?vs=35777&id=35778#toc Repository: rL LLVM http

Re: [PATCH] D12719: ScalarEvolution assume hanging bugfix

sanjoy added a comment. I don't think this is an infinite loop (Piotr, can you please verify this?), it is probably an O(n!) recursion where n == number of the assumptions. ScalarEvolution::isImpliedCond already guards for infinite loops via MarkPendingLoopPredicate. However, if you have assume

Re: [PATCH] D12719: ScalarEvolution assume hanging bugfix

> Both tests are protected by there being exactly one latch in the loop (we > exit early if there's not one latch). I'm not sure what makes the > LoopContinuePredicate check safer? You can have a loop with a single latch but an arbitrary number of assumes (= n). In such a loop, you'll still end u