[PATCH] D31120: [InstCombine] Teach SimplifyDemandedUseBits that adding or subtractings 0s from every bit below the highest demanded bit can be simplified

Daniel Berlin via llvm-commits llvm-commits at lists.llvm.org
Tue Mar 21 17:31:01 PDT 2017

Sure, which is why you define the semantics to something that makes sense
for exposing the issue?

How much state you reset/don't reset to accomplish that semantic is up to
you :)

But it's not like it's impossible to have skip have the semantic of "don't
do any actual changes for the first x iterations", it just may not be
trivial given the structure of instcombine ATM.  That never changes until
someone changes it :P
(and imho, i'd argue that's one reason these bugs creep in.  If it was
split up to be more easily testable, people may actually test it more)

On Tue, Mar 21, 2017 at 5:20 PM, Craig Topper <craig.topper at gmail.com>

> But the contents of the second iteration of the worklist could be very
> different based on what was skipped and what other changes happened in the
> first iteration.
> ~Craig
> On Tue, Mar 21, 2017 at 5:11 PM, Daniel Berlin <dberlin at dberlin.org>
> wrote:
>> On Tue, Mar 21, 2017 at 4:52 PM, Craig Topper via Phabricator via
>> llvm-commits <llvm-commits at lists.llvm.org> wrote:
>>> craig.topper added a comment.
>>> Yeah I saw that. Should we add a debug counter around the top level
>>> worklist loop? The semantics of the "skip" part of the counter wouldn't
>>> make sense though.
>>> That depends on what semantics you want out of it :)
>> FWIW: In NewGVN, we want the semantic of the value numbering counter to
>> to be "choose which  instructions are processed on each iteration of the
>> worklist".
>> There are two ways to accomplish that:
>> 1. Record which were skipped, skip them again (some cost)
>> or
>> 2. use the isCounterSet/etc to reset the counter at the start of  each
>> iteration of the worklist to the same values. (no cost if debug is off,
>> though i see i forgot to make this constant when #ifdef NDEBUG)
>>> https://reviews.llvm.org/D31120
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170321/ba9caa96/attachment.html>

More information about the llvm-commits mailing list