Page MenuHomePhabricator

nikic (Nikita Popov)
User

Projects

User does not belong to any projects.

User Details

User Since
May 5 2018, 9:37 AM (163 w, 2 d)

Recent Activity

Today

nikic added a comment to D104668: [OpaquePtr] Handle addrspacecasts in InstCombine.

Any thoughts on the approach here? Is the !isOpaque() ? getElementType() : nullptr pattern something we should add a helper function for? Not sure how common this is going to be outside these cast transforms.

Mon, Jun 21, 2:40 PM · Restricted Project
nikic updated the diff for D104668: [OpaquePtr] Handle addrspacecasts in InstCombine.

Use getWithSamePointeeType().

Mon, Jun 21, 2:31 PM · Restricted Project
nikic added a comment to D104503: [SCEV] Don't require dominance ordering of add/mul/min/max expressions.

@efriedma LICM still uses AST for scalar promotion.

Mon, Jun 21, 1:44 PM · Restricted Project
nikic requested review of D104668: [OpaquePtr] Handle addrspacecasts in InstCombine.
Mon, Jun 21, 1:39 PM · Restricted Project
nikic committed rG39796e1ad02a: Reapply [InstCombine] Don't try converting opaque pointer bitcast to GEP (authored by nikic).
Reapply [InstCombine] Don't try converting opaque pointer bitcast to GEP
Mon, Jun 21, 1:18 PM
nikic committed rGe2c2124a4b5b: Reapply [InstCombine] Extract bitcast -> gep transform (authored by nikic).
Reapply [InstCombine] Extract bitcast -> gep transform
Mon, Jun 21, 1:03 PM
nikic committed rG403792f91e82: [InstCombine] Add test for bitcast of unsized pointer (NFC) (authored by nikic).
[InstCombine] Add test for bitcast of unsized pointer (NFC)
Mon, Jun 21, 1:03 PM
nikic added a reverting change for rGd9f5d7b959de: [InstCombine] Extract bitcast -> gep transform: rG6922ab73a5a5: Revert "[InstCombine] Extract bitcast -> gep transform".
Mon, Jun 21, 12:34 PM
nikic added a reverting change for rG5780611d7e04: [InstCombine] Don't try converting opaque pointer bitcast to GEP: rG6922ab73a5a5: Revert "[InstCombine] Extract bitcast -> gep transform".
Mon, Jun 21, 12:34 PM
nikic committed rG6922ab73a5a5: Revert "[InstCombine] Extract bitcast -> gep transform" (authored by nikic).
Revert "[InstCombine] Extract bitcast -> gep transform"
Mon, Jun 21, 12:34 PM
nikic committed rG862313cf59ee: [LoopUnroll] Don't modify TripCount/TripMultiple in computeUnrollCount() (NFCI) (authored by nikic).
[LoopUnroll] Don't modify TripCount/TripMultiple in computeUnrollCount() (NFCI)
Mon, Jun 21, 12:34 PM
nikic closed D104590: [LoopUnroll] Don't modify TripCount/TripMultiple in computeUnrollCount().
Mon, Jun 21, 12:34 PM · Restricted Project
nikic added inline comments to D104661: [InstSimplify] Add more poison folding optimizations.
Mon, Jun 21, 12:30 PM · Restricted Project
nikic committed rG5780611d7e04: [InstCombine] Don't try converting opaque pointer bitcast to GEP (authored by nikic).
[InstCombine] Don't try converting opaque pointer bitcast to GEP
Mon, Jun 21, 12:25 PM
nikic committed rGd9f5d7b959de: [InstCombine] Extract bitcast -> gep transform (authored by nikic).
[InstCombine] Extract bitcast -> gep transform
Mon, Jun 21, 12:25 PM
nikic committed rGa969bdc56f66: [InstCombine] Remove unnecessary addres space check (NFC) (authored by nikic).
[InstCombine] Remove unnecessary addres space check (NFC)
Mon, Jun 21, 11:14 AM
nikic committed rGd9fe96fe264e: [OpaquePtr] Support opaque constant expression GEP (authored by nikic).
[OpaquePtr] Support opaque constant expression GEP
Mon, Jun 21, 11:09 AM
nikic closed D104655: [OpaquePtr] Support opaque constant expression GEP.
Mon, Jun 21, 11:09 AM · Restricted Project
nikic requested review of D104655: [OpaquePtr] Support opaque constant expression GEP.
Mon, Jun 21, 9:41 AM · Restricted Project
nikic committed rG9f779195d311: [OpaquePtr] Return opaque pointer from opaque pointer GEP (authored by nikic).
[OpaquePtr] Return opaque pointer from opaque pointer GEP
Mon, Jun 21, 9:38 AM
nikic closed D104652: [OpaquePtr] Return opaque pointer from opaque pointer GEP.
Mon, Jun 21, 9:38 AM · Restricted Project
nikic added a comment to D104652: [OpaquePtr] Return opaque pointer from opaque pointer GEP.

lgtm

what about GEP constants? do we need to do something special for those in ValueEnumerator?

Mon, Jun 21, 9:12 AM · Restricted Project
nikic requested review of D104652: [OpaquePtr] Return opaque pointer from opaque pointer GEP.
Mon, Jun 21, 8:45 AM · Restricted Project
nikic requested review of D104648: [Mem2Reg] Use poison instead of undef for read of uninitialized memory.
Mon, Jun 21, 8:02 AM · Restricted Project
nikic committed rGacefe0eaaf82: [Mem2Reg] Regenerate test checks (NFC) (authored by nikic).
[Mem2Reg] Regenerate test checks (NFC)
Mon, Jun 21, 2:07 AM
nikic committed rG80e0424b2ce9: [Mem2Reg] Use poison for unreachable cases (authored by nikic).
[Mem2Reg] Use poison for unreachable cases
Mon, Jun 21, 1:54 AM
nikic committed rG00a88a81d2ad: [Mem2Reg] Regenerate test checks (NFC) (authored by nikic).
[Mem2Reg] Regenerate test checks (NFC)
Mon, Jun 21, 1:48 AM
nikic accepted D96663: [InstCombine] Fold icmp (select c,const,arg), null if icmp arg, null can be simplified.

LGTM

Mon, Jun 21, 12:40 AM · Restricted Project

Yesterday

nikic committed rG1ae266f4529f: [LoopUnroll] Use smallest exact trip count from any exit (authored by nikic).
[LoopUnroll] Use smallest exact trip count from any exit
Sun, Jun 20, 12:02 PM
nikic closed D102982: [LoopUnroll] Use smallest exact trip count from any exit.
Sun, Jun 20, 12:01 PM · Restricted Project
nikic updated the diff for D102982: [LoopUnroll] Use smallest exact trip count from any exit.

Update comment.

Sun, Jun 20, 7:49 AM · Restricted Project
nikic accepted D104602: [InstCombine] Use poison constant to represent the result of unreachable instrs.

LGTM, but please drop the "use poison instead of undef" comments -- I don't think using poison instead of undef for dead code requires any explicit justification.

Sun, Jun 20, 2:28 AM · Restricted Project

Sat, Jun 19

nikic updated the diff for D104590: [LoopUnroll] Don't modify TripCount/TripMultiple in computeUnrollCount().

Remove outdated comment.

Sat, Jun 19, 12:31 PM · Restricted Project
nikic added inline comments to D102982: [LoopUnroll] Use smallest exact trip count from any exit.
Sat, Jun 19, 12:29 PM · Restricted Project
nikic added inline comments to D102982: [LoopUnroll] Use smallest exact trip count from any exit.
Sat, Jun 19, 11:46 AM · Restricted Project
nikic added inline comments to D104590: [LoopUnroll] Don't modify TripCount/TripMultiple in computeUnrollCount().
Sat, Jun 19, 11:14 AM · Restricted Project
nikic updated the diff for D104590: [LoopUnroll] Don't modify TripCount/TripMultiple in computeUnrollCount().

Remove obsolete unroll count clamp.

Sat, Jun 19, 11:11 AM · Restricted Project
nikic added a comment to D104569: [SimplifyCFG] Fix SimplifyBranchOnICmpChain to be undef/poison safe..

I have a general policy question here: Do we care about miscompiles that are caused by undef, but not poison? This makes a difference for transforms like these, e.g. no freeze is required if the condition is first in a logical or (or at any position in bitwise or) if we only care about poison.

Sat, Jun 19, 8:07 AM · Restricted Project
nikic updated the diff for D102982: [LoopUnroll] Use smallest exact trip count from any exit.

Rebase, and only consider TripCount for all exits, leave TripMultiple alone for now to minimize impact.

Sat, Jun 19, 1:46 AM · Restricted Project
nikic added inline comments to D104590: [LoopUnroll] Don't modify TripCount/TripMultiple in computeUnrollCount().
Sat, Jun 19, 1:28 AM · Restricted Project
nikic requested review of D104590: [LoopUnroll] Don't modify TripCount/TripMultiple in computeUnrollCount().
Sat, Jun 19, 1:20 AM · Restricted Project
nikic abandoned D103026: [LoopUnroll] Explicitly specify exit to unroll against (NFCI).

No longer needed, UnrollLoop() is no longer passed TripCount/TripMultiple for a specific exit.

Sat, Jun 19, 12:34 AM · Restricted Project
nikic committed rG1bd4085e0bbc: [LoopUnroll] Push runtime unrolling decision up into tryToUnrollLoop() (authored by nikic).
[LoopUnroll] Push runtime unrolling decision up into tryToUnrollLoop()
Sat, Jun 19, 12:33 AM
nikic closed D104487: [LoopUnroll] Push runtime unrolling decision up into tryToUnrollLoop().
Sat, Jun 19, 12:32 AM · Restricted Project

Fri, Jun 18

nikic committed rG3308205ae9dd: [LoopUnroll] Simplify optimization remarks (authored by nikic).
[LoopUnroll] Simplify optimization remarks
Fri, Jun 18, 2:49 PM
nikic closed D104482: [LoopUnroll] Simplify optimization remarks.
Fri, Jun 18, 2:49 PM · Restricted Project
nikic updated the diff for D104482: [LoopUnroll] Simplify optimization remarks.

What do you think about this variant? It prints information for all exits as debug output, but keeps optimization remarks basic.

Fri, Jun 18, 11:45 AM · Restricted Project
nikic added a comment to D104482: [LoopUnroll] Simplify optimization remarks.

I think I would prefer to see the information for each exit as opposed to removing it entirely. When understanding why unrolling happened in a particular way, having the detailed information is often very helpful. Not a strong preference, I'm willing to LGTM this if you really object.

Fri, Jun 18, 11:07 AM · Restricted Project
nikic accepted D103959: [LoopDeletion] Handle Phis with similar inputs from different block.

Not seeing any compile-time impact, and rebased versions still looks good.

Fri, Jun 18, 5:43 AM · Restricted Project
nikic accepted D102615: [LoopDeletion] Break backedge if we can prove that the loop is exited on 1st iteration (try 3).

LGTM

Fri, Jun 18, 1:38 AM · Restricted Project
nikic added a comment to D102615: [LoopDeletion] Break backedge if we can prove that the loop is exited on 1st iteration (try 3).

Compile-time with the reference invalidation issue fixed: https://llvm-compile-time-tracker.com/compare.php?from=b5c4fc0f232b6368bbd7cd8681a6931f2c30ad02&to=9bb9b602fd58e6fdd353cdfedec56980a40230c1&stat=instructions Impact is small and without outliers. I think this is as cheap as it gets :)

Fri, Jun 18, 12:15 AM · Restricted Project

Thu, Jun 17

nikic added a comment to D102615: [LoopDeletion] Break backedge if we can prove that the loop is exited on 1st iteration (try 3).

Still crashing, here's the backtrace:

ld: /home/nikic/llvm-project/llvm/include/llvm/Support/Casting.h:104: static bool llvm::isa_impl_cl<To, const From*>::doit(const From*) [with To = llvm::Constant; From = llvm::Value]: Assertion `Val && "isa<> used on a null pointer"' failed.
Thu, Jun 17, 2:54 PM · Restricted Project
nikic added inline comments to D104487: [LoopUnroll] Push runtime unrolling decision up into tryToUnrollLoop().
Thu, Jun 17, 1:50 PM · Restricted Project
nikic updated the diff for D104487: [LoopUnroll] Push runtime unrolling decision up into tryToUnrollLoop().

Fix comment typos.

Thu, Jun 17, 1:46 PM · Restricted Project
nikic requested review of D104487: [LoopUnroll] Push runtime unrolling decision up into tryToUnrollLoop().
Thu, Jun 17, 1:44 PM · Restricted Project
nikic requested review of D104482: [LoopUnroll] Simplify optimization remarks.
Thu, Jun 17, 12:28 PM · Restricted Project
nikic committed rGf7c54c4603a2: [LoopUnroll] Fold all exits based on known trip count/multiple (authored by nikic).
[LoopUnroll] Fold all exits based on known trip count/multiple
Thu, Jun 17, 11:59 AM
nikic closed D104203: [LoopUnroll] Fold all exits based on known trip count/multiple.
Thu, Jun 17, 11:58 AM · Restricted Project
nikic added a comment to D102615: [LoopDeletion] Break backedge if we can prove that the loop is exited on 1st iteration (try 3).

It looks like the new implementation causes a segfault while building 7zip using the ReleaseLTO-g configuration: https://llvm-compile-time-tracker.com/show_error.php?commit=77e65ca9acb9db4de64a1ff8002f1d53470a0de3

Thu, Jun 17, 5:39 AM · Restricted Project
nikic added a comment to D102615: [LoopDeletion] Break backedge if we can prove that the loop is exited on 1st iteration (try 3).

Cut down to non-recursive reasoning. @nikic could you please check the CT impact? If it's now, then it's all about complex recursive rules of proof, and this is where we can seek to simplify SCEV's reasoning.

Thu, Jun 17, 3:25 AM · Restricted Project
nikic added a comment to D102615: [LoopDeletion] Break backedge if we can prove that the loop is exited on 1st iteration (try 3).

This is surprising to me -- why does this require changes to InstSimplify?

InstSimplify does not provide public API for this:

const SCEV *LHSS = getSCEVOnFirstIteration(LHS, L, SE, FirstIterSCEV);
const SCEV *RHSS = getSCEVOnFirstIteration(RHS, L, SE, FirstIterSCEV);
S = SE.getAddExpr(LHSS, RHSS);

It has SimplifyAddInst that works with custom arguments, but it's currently static within the cpp file. I'd need to expose all of them. At least this, maybe more.

Thu, Jun 17, 3:05 AM · Restricted Project
nikic added a comment to D102615: [LoopDeletion] Break backedge if we can prove that the loop is exited on 1st iteration (try 3).

Currently scheming a prototype to see if it works. My speculation is InstSimplify might be enough for my motivating example. However, this will require massive refactoring of InstSimplify itself (some of its static functions will need to be made publicly available). It's a lot of work just to duplicate a part of what SCEV does out of box.

Thu, Jun 17, 2:46 AM · Restricted Project

Wed, Jun 16

nikic added a comment to D102615: [LoopDeletion] Break backedge if we can prove that the loop is exited on 1st iteration (try 3).

As for SCEV impact, some points.

  1. Yes, I agree that we should try to reduce impact on compile time when we can;
  2. We already have passes (IV simplify, IRCE, LSR...) where we already use SCEV. I'm absoultely certain that in reality, most things they do they could handle with InstSimplify-like instructions. But for some reason, we don't mind against the toll that SCEV takes there (and it should be HUGE in IV simplify) just because we started tracking compile time *after* these things were already there.
  3. It's pretty clear to me that the problem is not in loop deletion that is slow with SCEV. The problem is that the SCEV is slow. And it's much slower than 0.2% that we see here. Holding away future optimizations just because SCEV is, and always has been, slow, doesn't seem right to me.
Wed, Jun 16, 2:24 PM · Restricted Project
nikic added inline comments to D104203: [LoopUnroll] Fold all exits based on known trip count/multiple.
Wed, Jun 16, 11:29 AM · Restricted Project
nikic added a comment to D104203: [LoopUnroll] Fold all exits based on known trip count/multiple.

I think there's a problem with this code, but I'm surprised the existing test didn't catch it. Have you run this with explicit dom tree and loop info validation enabled?

Here's the problem I think I see. If we have an exit block which exits only on iteration X, and we unroll by count Y where Y > X, I believe we'll end up making the exit block unreachable. (This can't happen if there's only a single exit since that exit must be reached.) The problem with an unreachable exit is that there can be arbitrarily complicated loops reachable only through that path, and updating loop info in that case is hard. Am I missing something here?

Wed, Jun 16, 11:19 AM · Restricted Project
nikic added a comment to D104322: [SCEV] PtrToInt on non-integral pointers is allowed.

As a drive-by note, it would be great if you could expand LangRef on non-integral pointers a bit. It made sense to me when it specified that you can't use ptrtoint on a non-integral pointer, but without that limitation, it's not really clear to me what the actual difference between a non-integral pointer and a normal one is. What transforms are you not allowed to perform on a non-integral pointer that you can perform on a normal one?

Wed, Jun 16, 8:24 AM · Restricted Project

Tue, Jun 15

nikic added a reviewer for D104296: [SCCP] Remove code redundancy in resolvedUndefsIn: fhahn.
Tue, Jun 15, 10:25 AM · Restricted Project
nikic added inline comments to D103009: [DSE] Transform memset + malloc --> calloc (PR25892).
Tue, Jun 15, 3:56 AM · Restricted Project

Mon, Jun 14

nikic added a comment to D103316: Hoist llvm.assume into single predecessor if block otherwise empty.

@bjope This SimplifyCFG patch allows us to remove the assume dropping code in CGP subsequently.

Mon, Jun 14, 1:14 PM · Restricted Project
nikic accepted D104238: [LoopDeletion] Check for irreducible cycles when deleting loops..

LGTM

Mon, Jun 14, 12:53 PM · Restricted Project

Sun, Jun 13

nikic requested review of D104203: [LoopUnroll] Fold all exits based on known trip count/multiple.
Sun, Jun 13, 12:25 PM · Restricted Project
nikic committed rG6ecc99210cdc: [LoopUnroll] Test multi-exit runtime unrolling with predictable exit (NFC) (authored by nikic).
[LoopUnroll] Test multi-exit runtime unrolling with predictable exit (NFC)
Sun, Jun 13, 9:49 AM

Sat, Jun 12

nikic added a reviewer for D104184: [Coroutine] Properly deal with byval and noalias parameters: efriedma.
Sat, Jun 12, 2:33 PM · Restricted Project
nikic added a comment to D102615: [LoopDeletion] Break backedge if we can prove that the loop is exited on 1st iteration (try 3).

SCEV is much more powerful in terms of simplification. Imagine the situation when some Phi takes value of a + b + c on the 1st iteration (and unknown on all others), then gets subtracted by a, then by b, and then by c, and then the result is compared against zero. If we want InstSimplify to do something like this, we will need to re-implement recrusive expression aggregation, simplification, in summary - we will need to re-invent SCEV.

I'm also sceptical about the approach that we are following (cripple the opts to save compile time). I'd rather prefer it to be isKnownPredicateAt, maybe under a flag, to use as much power as it can.

If the SCEV's CT impact is still unacceptable, we can cripple it even further to use isKnownViaNonRecursiveReasoning, but basically in this case we can just go with -O0 and stay happy about the results.

Sat, Jun 12, 3:12 AM · Restricted Project

Fri, Jun 11

nikic added inline comments to D103844: [SCEV] Cache wrap facts for positive IVs w/LT exits.
Fri, Jun 11, 2:04 PM · Restricted Project
nikic added inline comments to D103844: [SCEV] Cache wrap facts for positive IVs w/LT exits.
Fri, Jun 11, 11:36 AM · Restricted Project
nikic accepted D104113: [SLP]Remove unnecessary UndefValue in CreateShuffle..

LGTM, thanks!

Fri, Jun 11, 6:10 AM · Restricted Project
nikic added a comment to D104099: [NewPM] Remove SpeculateAroundPHIs pass.

Looks like phase ordering tests need an update.

Fri, Jun 11, 3:33 AM · Restricted Project, Restricted Project
nikic added a comment to D104075: [ScalarEvolution] Merge howManyGreaterThans with howManyLessThans..

There's a minor compile-time impact for this refactoring: https://llvm-compile-time-tracker.com/compare.php?from=57006d2f6d96d8a6836ae901218ed615071b3b8e&to=eca6ad2e31d754420fb114872bfc4060a698155e&stat=instructions It's okay, but you might want to cut down on the number of repeated/redundant getNotSCEV operations you perform. (They're not cached and known to be somewhat expensive.)

Fri, Jun 11, 3:30 AM · Restricted Project
nikic added a comment to D95789: [SpeculateAroundPHIs] Avoid speculation on loop back edges.

It seems like the addition of this patch has been somewhat botched by adding it only to the NewPM pipeline -- for no clear reason I can discern. This was at a time where barely anyone (outside Google) was using the NewPM, which means that this received very little evaluation from other parties. Now people are hitting this as part of the LegacyPM -> NewPM migration instead, which really shouldn't be the case.

Fri, Jun 11, 1:54 AM · Restricted Project

Thu, Jun 10

nikic added inline comments to D104007: [BasicAA] Properly mark that coroutine suspension may modify parameters.
Thu, Jun 10, 2:12 PM · Restricted Project
nikic added inline comments to D104057: [SLP]Allow reordering of insertelements..
Thu, Jun 10, 2:02 PM · Restricted Project
nikic added a comment to D103834: [SCEV] Properly guard reasoning about infinite loops being UB on mustprogress.

Sorry, I used wrong example in the link. I've changed it to something where I do "i += n" instead of "i += n/2".

Is perhaps the problem that "i += n" might overflow (UB) and thereby we can't guarantee "must progress"?

Thu, Jun 10, 10:08 AM · Restricted Project
nikic added a comment to D103834: [SCEV] Properly guard reasoning about infinite loops being UB on mustprogress.

One thing that might cause problems here is that it seems like getting the MustProgress attribute on a Function is quite hard. It is basically inferred by having WillReturn on the Function, and afaict the WillReturn attribute is never inferred if the Functions contain loops.

In the godbolt example above the Function has no MustProgress attribute, however the loop has a MustProgress attribute. So maybe loopIsFiniteByAssumption should check if the loop has MustProgress as well?

Thu, Jun 10, 9:47 AM · Restricted Project

Wed, Jun 9

nikic added inline comments to D103844: [SCEV] Cache wrap facts for positive IVs w/LT exits.
Wed, Jun 9, 3:16 PM · Restricted Project
nikic accepted D103844: [SCEV] Cache wrap facts for positive IVs w/LT exits.

LGTM

Wed, Jun 9, 2:58 PM · Restricted Project
nikic accepted D99173: Intrinsic::getName: require a Module argument.

LGTM

Wed, Jun 9, 2:02 PM · Restricted Project
nikic resigned from D99596: [LoopDist] Distribute vectorizable loops.
Wed, Jun 9, 1:48 PM · Restricted Project
nikic requested changes to D101510: Do not merge memcpy if the first source is a parameter of coroutine function.

It looks like a different fix is being pursued, so marking this as changes requested to move it off the review queue.

Wed, Jun 9, 1:47 PM · Restricted Project
nikic added inline comments to D103451: [SimplifyLibCalls][NFC] Clean up LibCallSimplifier from memset+malloc into calloc transformation.
Wed, Jun 9, 1:42 PM · Restricted Project
nikic added inline comments to D103009: [DSE] Transform memset + malloc --> calloc (PR25892).
Wed, Jun 9, 1:34 PM · Restricted Project
nikic added a comment to D101103: [InstSimplify] Treat invariant group insts as bitcasts for load operands.

While it may make sense to address this in JumpThreading in addition, I believe InstSimplify is intended to be robust against unreachable code. As InstSimplify can thread over phis, I don't think it's even possible for a caller to reliably prevent unreachable code from reaching InstSimplify.

Wed, Jun 9, 1:08 PM · Restricted Project
nikic added a comment to D101722: [SCEV] Don't require ControlsExit for gt/lt NoWrap.

If I'm understanding correctly, the issue you're describing is that if %len is ULONG_MAX in the following loop, on trunk LLVM, the backedge-taken count comes out to zero.

Wed, Jun 9, 10:11 AM · Restricted Project
nikic requested changes to D103844: [SCEV] Cache wrap facts for positive IVs w/LT exits.

Per above comment

Wed, Jun 9, 9:48 AM · Restricted Project
nikic accepted D103959: [LoopDeletion] Handle Phis with similar inputs from different block.

LGTM

Wed, Jun 9, 9:45 AM · Restricted Project

Tue, Jun 8

nikic planned changes to D101722: [SCEV] Don't require ControlsExit for gt/lt NoWrap.

Okay, I think the change is not right after all. In particular, if we have an exit count like ((1 + %len) /u 2) that does represent the right exit count in arbitrary precision (via either exit or executed UB), but the expression for calculating the exit count itself may still overflow. If %len is UINT_MAX then the resulting exit count would be 0, while it should be UINT_MAX/2 (which is the iteration at which UB occurs). That's clearly not right.

Tue, Jun 8, 1:16 PM · Restricted Project
nikic accepted D103877: [SCEV] Keep common NUW flags when inlining Add operands..

LGTM

Tue, Jun 8, 1:05 PM · Restricted Project
nikic added inline comments to D103844: [SCEV] Cache wrap facts for positive IVs w/LT exits.
Tue, Jun 8, 9:50 AM · Restricted Project

Mon, Jun 7

nikic added a comment to D102615: [LoopDeletion] Break backedge if we can prove that the loop is exited on 1st iteration (try 3).

After looking through the tests, why does this need to use SCEV at all? As far as I can tell, simply using InstSimplify would be sufficient to prove all these cases (or just ConstFold for that matter). Without isKnownPredicateAt(), where symbolic reasoning is necessary, SCEV doesn't seem to provide much value here, or at least it's not obvious from the tests. (Of course, there will be cases where it can do more, but the converse also holds -- in particular, InstSimplify/ConstFold support arbitrary instructions, no need to special-case a limited set of them.)

Mon, Jun 7, 1:31 PM · Restricted Project
nikic accepted D103831: [BasicAA] Handle PHIs without incoming values gracefully.

LGTM. I was going to suggest that you add a direct AA test, but apparently there is no way to write an empty phi in textual LLVM IR, at least not that I can see. Weird limitation.

Mon, Jun 7, 12:21 PM · Restricted Project