dberlin (Daniel Berlin)
User

Projects

User does not belong to any projects.

User Details

User Since
Jul 13 2012, 1:07 PM (292 w, 5 d)

Recent Activity

Today

dberlin added a comment to D40874: [LV][LoopInfo] Add irreducible CFG detection for outer loops.

Thanks, that is very helpful. It's much more likely that Dominator info is up to date than loop info, but it's not worth getting into here. The only thing I request is that you update the comments to suggest this only probably makes sense to use if loopinfo is computed already, and please just add your description of how it works with the example to the comments.

Wed, Feb 21, 6:11 PM

Yesterday

dberlin added a comment to D40874: [LV][LoopInfo] Add irreducible CFG detection for outer loops.

Hey, can you help me understand the algorithm?
I don't have a good feel for the invariants you expect going in.
It just says "it works on anything given loop info".
IE What info you expect the loopinfo to provide vs the topo ordering.

Tue, Feb 20, 12:58 PM

Sun, Feb 18

dberlin added a comment to D43269: [MemorySSA] Be less aggressive with @llvm.lifetime.start.

To be clear, i think the lifetime system has enough issues that trying to cover it with MemorySSA as it currently exists wouldn't end up well.
Things that want to care about and try to optimize around lifetimes can do that.
Intermixing object lifetime and aliasing results in the same system will, IMHO, give you a bad time.

Sun, Feb 18, 2:26 PM

Fri, Feb 16

dberlin added a comment to D43349: [InstCombine] Make SimplifyDemandedUseBits handle PhiNode.

Interesting. NewGVN can already figure this out if it's important.
How often does stuff like this occur?

Fri, Feb 16, 11:04 AM

Thu, Feb 15

dberlin added a comment to D43269: [MemorySSA] Be less aggressive with @llvm.lifetime.start.

Oh god i've been away from LLVM too long.
So, i don't know what we *want* the semantic to be.
Can you print the memoryssa dumps for this for me?
Add hal, etc, get his thoughts

Thu, Feb 15, 12:18 PM

Wed, Feb 14

dberlin added a comment to D43173: [CallSiteSplitting] Preserve DominatorTreeAnalysis..

Personally, i totally think this is worthwhile and worth spending some time on to prevent the slow proliferation of 10+ argument functions taking analysis results. Because that's the path we are heading down, and that's definitely hard to refactor, change, etc
But i'm also not the person who would do the work (though happy to review).

Wed, Feb 14, 2:44 PM

Tue, Feb 13

dberlin added a comment to D42551: [Debug] Add dbg.value intrinsics for PHIs created during LCSSA..

This adds another basic block walk per InstBB, because llvm::insertDebugValuesForPHIs walks the entire bb :(

Tue, Feb 13, 10:33 AM
dberlin added a comment to D43173: [CallSiteSplitting] Preserve DominatorTreeAnalysis..

An example of that is getBestSimplifyQuery, which takes various analysis managers, etc, and extracts the analysis it cares about them.
If we did similar, we could simplify what gets passed through and easily add updating of a new thing.

Tue, Feb 13, 10:23 AM
dberlin accepted D43173: [CallSiteSplitting] Preserve DominatorTreeAnalysis..
Tue, Feb 13, 10:22 AM
dberlin added a comment to D43173: [CallSiteSplitting] Preserve DominatorTreeAnalysis..

So this looks right to me.
I'm a little worried about how we are having to modify tons and tons of functions to push these through.
When we get to postdominator updates, we'll have to do the same thing.

Tue, Feb 13, 10:21 AM
dberlin added inline comments to D42717: [JumpThreading] sync DT for LVI analysis (PR 36133).
Tue, Feb 13, 8:51 AM

Mon, Feb 12

dberlin added a comment to D43173: [CallSiteSplitting] Preserve DominatorTreeAnalysis..

Please use getAnalysisIfAvailable for the old pass manager
Please use getCachedResult for the new pass manager.

Mon, Feb 12, 10:18 AM

Wed, Feb 7

dberlin added a comment to D42717: [JumpThreading] sync DT for LVI analysis (PR 36133).

LVI functions fine without DT, and it's going to be too expensive to ever use a lazy analysis that is constantly recomputing info like LVI because it may require hundreds or thousands of Dominator tree rebuilds. I would hand LVI a fake dt pointer class where when the Dominator tree is up to date, it works and when it's not up to date, it is null. That would work with how LVI currently checking I think. Regardless I think the right answer here is to make it not use it when it's not up to date. That will give better answers then it used to get and you get gradually better answers as you can preserve more or become less lazy

Wed, Feb 7, 3:47 PM

Fri, Feb 2

dberlin added a comment to D42805: [utils] Refactor utils/update_{,llc_}test_checks.py to share more code.

These were actually deliberately split apart in the past year, so not sure what makes sense here.

Fri, Feb 2, 9:08 AM

Tue, Jan 30

dberlin added a comment to D34135: [JumpThreading] Use DT to avoid processing dead blocks.

(also, the DT was not updated at all prior during JT prior to all of these patches, so i guess it all worked because LVI didn't use DT when called from JumpThreading or something)?

Tue, Jan 30, 8:38 AM
dberlin added a comment to D34135: [JumpThreading] Use DT to avoid processing dead blocks.

I think PR36133 could be considered a different issue. LVI currently uses a domtree for certain queries involving llvm.assume; to make that work, the domtree would have to be up-to-date every time we call into LVI. But we could solve that separately from the problem of dead code in LVI.

Tue, Jan 30, 8:36 AM

Mon, Jan 29

dberlin added a comment to D34135: [JumpThreading] Use DT to avoid processing dead blocks.

Err, looking at that bug, it looks like it occurs in release versions before the dominance update patch was ever submitted :)

Mon, Jan 29, 9:48 AM

Jan 22 2018

dberlin added a comment to D42311: [SyntheticCounts] Rewrite the code using only graph traits..

Is it a thing that is even different for each callgraph implementation? (If not, why is it a trait?)
Even if it is, if you look, you'll see we don't try to encode random computed Node property differences in GraphTraits. Only the things that *every* graph algorithm needs (IE it caters to anything, not everything). Random node property differences are handled through other trait classes or filtering. This does not, at a glance, seem like a thing that literally every algorithm that is going to use a Callgraph needs. It looks like one that some may need. You even prove this yourself.

Jan 22 2018, 5:20 PM
dberlin added a comment to D42311: [SyntheticCounts] Rewrite the code using only graph traits..

I don't understand why you need has_function_def. It looks very much like a thing you should just be using a filter_iterator for or something. It does not look like it belongs in the graphtraits at all.

Jan 22 2018, 4:01 PM
dberlin accepted D42337: [Dominators] Introduce DomTree verification levels .

@dberlin:

I assume if we ever bothered to make the verification O(N) again using better algorithms, we'd go back to one level of verification?

I think it's very unlikely that someone will implement this in the foreseeable future.

Jan 22 2018, 10:58 AM

Jan 19 2018

dberlin added a comment to D42311: [SyntheticCounts] Rewrite the code using only graph traits..

I like the idea here a lot, but i don't understand why you need to make a new type of graph traits with things called call_edge_begin/end.
Can you explain the necessity here?
(IE why can you just not implement a graphtraits, why do you need a callgraphtraits)

Jan 19 2018, 12:55 PM

Jan 17 2018

dberlin added a comment to D42179: [NewGVN] Re-evaluate phi of ops after moving an instr to new class .

To try to help explain this (and feel free to turn it into a comment in NewGVN), for a phi of ops, let me try to cover the cases.

Jan 17 2018, 12:56 PM
dberlin added a comment to D42179: [NewGVN] Re-evaluate phi of ops after moving an instr to new class .

At a glance, i don't believe this is correct.
The ClassChanged part above should have already done this.
If not, can you detail me how it is happening?

What follows is my initial understanding after starting having a look at NewGVN and I am probably missing a couple of things. I would greatly appreciate any thoughts and pointers :)

I think the problem is the following: ExpressionToPhiOfOps is used to re-process the phi-of-ops, in case the leader of the symbolic (gvn) expression changed.

Yes, that is true, but that case should only occur if we have not created a phi of ops, and need to mark what will happen later.

Jan 17 2018, 12:39 PM
dberlin added a comment to D42179: [NewGVN] Re-evaluate phi of ops after moving an instr to new class .

Note also that we mark all operands that are part of the expression as Deps. If the leader of those operands changed, they would already be marked as changed as Users through the addAdditionalUsers part we do.

Jan 17 2018, 8:07 AM
dberlin added a comment to D42180: [NewGVN] Re-evaluate phi of ops if expr operands change. .

This is definitely not right, unfortunately.

Jan 17 2018, 8:06 AM
dberlin added a comment to D42179: [NewGVN] Re-evaluate phi of ops after moving an instr to new class .

At a glance, i don't believe this is correct.
The ClassChanged part above should have already done this.
If not, can you detail me how it is happening?

Jan 17 2018, 8:03 AM

Jan 5 2018

dberlin added a comment to D41689: [SCEVAA] Don't crash on pointers with no dominance relationship..

First, it's definitely the case that you can't compute the difference for all SCEVs. It's equivalent to being able to symbolically executing the program with only static information :)

Jan 5 2018, 2:01 PM

Jan 3 2018

dberlin accepted D41605: StructurizeCFG: Fix broken backedge detection.

LGTM

Jan 3 2018, 10:01 AM

Dec 28 2017

dberlin accepted D41418: IR: Fix BasicBlock::phis for empty blocks.
Dec 28 2017, 6:26 PM

Dec 27 2017

dberlin added a comment to D41605: StructurizeCFG: Fix broken backedge detection.

Reading the old code you are replacing I don't feel like I understand the graph theory behind the algorithm.

Dec 27 2017, 6:53 PM

Nov 29 2017

dberlin added inline comments to D40480: MemorySSA backed Dead Store Elimination. .
Nov 29 2017, 1:11 AM

Nov 27 2017

dberlin added a comment to D40304: [InstCombine] PR35354: Convert load bitcast (select (Cond, &V1, &V2)) --> select(Cond, load bitcast &V1, load bitcast &V2).

So, what Sanjoy has pointed out is that canonicalization like this to select, breaks the ability to remove redundant loads and stores and do PRE, compared to the equivalent control flow version, in general.

Nov 27 2017, 12:35 PM

Nov 26 2017

dberlin added a comment to D40427: [ADT] Introduce Disjoint Set Union structure.

Two things.
First, to bikeshed this horribly:

Nov 26 2017, 11:45 PM

Nov 14 2017

dberlin accepted D39630: [PredicateInfo] Stable sort ValueDFS to remove non-deterministic ordering.
Nov 14 2017, 10:17 AM

Nov 10 2017

dberlin added a comment to D39835: [GVN PRE] Clear nsw/nuw for original values in LoadPRE.

Yeah, I filed a bug about this when we started the first review, its good to have a real testcasr

Nov 10 2017, 5:56 PM

Nov 9 2017

dberlin added a comment to D39835: [GVN PRE] Clear nsw/nuw for original values in LoadPRE.

Sorry, I didn't really look at the jump-threading testcase in the other patch. (In general, it's bad practice to write testcases which involve multiple passes because it confuses the issue you're actually trying to fix.) We don't need to strip the nsw in pre-jt-add.ll from the other patch, and we don't need to strip nsw for this testcase.

The PRE transform in the testcase in this patch can be split into two parts: one, we clone the load and move it into the predecessors, and two, we eliminate the fully redundant loads. Cloning the load is obviously safe: it's the same operation. Eliminating the fully redundant load is also safe: storing the value to memory and loading it does not change it. Stores do not erase poison; you just get poisoned memory.

Nov 9 2017, 8:15 PM
dberlin added a comment to D39835: [GVN PRE] Clear nsw/nuw for original values in LoadPRE.

Errr, outside of an irrelevant store, it generates literally the same output and jump threading result as: https://reviews.llvm.org/rL317768

Nov 9 2017, 1:28 PM
dberlin added inline comments to D39781: [GVNHoist] Fix: PR35222 gvn-hoist incorrectly erases load.
Nov 9 2017, 10:34 AM

Nov 8 2017

dberlin accepted D39637: [GVN PRE] Patch the source for Phi node in PRE.

That's fine too.

Nov 8 2017, 9:01 PM
dberlin added a comment to D39637: [GVN PRE] Patch the source for Phi node in PRE.

Can you please fix LoadPRE as well?
ConstructSSALoadSet needs to be patching instructions it materializes if they come from an existing value.

Nov 8 2017, 8:59 PM
dberlin added a comment to D39637: [GVN PRE] Patch the source for Phi node in PRE.

In load PRE, it is replacing the value of a load with a phi of other values.

Nov 8 2017, 3:40 PM
dberlin added a comment to D39637: [GVN PRE] Patch the source for Phi node in PRE.

Your patch has convinced me that GVN is probably generally broken here, but just happens to not value number or create new phi nodes except for PRE, so it doesn't generate a lot of instances of this issue.
So yeah, i'm fine with the patch in general

Nov 8 2017, 1:51 PM

Nov 6 2017

dberlin added a comment to D39637: [GVN PRE] Patch the source for Phi node in PRE.

I think it would be a lot easier to understand your example if you could produce IR that, when run through -gvn -enable-pre -jump-threading, produces the wrong result without this patch.

Nov 6 2017, 9:07 PM
dberlin added a comment to D39637: [GVN PRE] Patch the source for Phi node in PRE.

TL; DR I'm .. confused.

Nov 6 2017, 8:36 PM

Oct 31 2017

dberlin added a comment to D39467: PR34603 Fix by Early-CSE extension.

I'll repeat what i said on the bug
FWIW: Given the choice, i would much rather fix the underlying problem then patch various passes to work around some small subset of it (here, load of selected addresses)
This is underway right now, actually.

Oct 31 2017, 12:28 PM

Oct 29 2017

dberlin accepted D39410: [GVNHoist] Fix non-deterministic sort order of PHIs for identical instructions.
Oct 29 2017, 10:36 PM

Oct 27 2017

dberlin added a comment to D39340: Modifying reassociate for improved CSE.

This seems very similar to what n-ary reassociate wants to do, I'd like to understand why we shouldn't do it there?
(where it seems to fit perfectly)

Oct 27 2017, 12:07 PM

Oct 26 2017

dberlin added inline comments to D38944: [GVN] Handle removal of first implicit CF instruction correctly.
Oct 26 2017, 11:01 AM

Oct 25 2017

dberlin added inline comments to D38862: Add must alias info to ModRefInfo..
Oct 25 2017, 7:44 PM

Oct 23 2017

dberlin accepted D39025: [GVNSink] Fix failing GVNSink tests in the reverse iteration bot.
Oct 23 2017, 11:15 AM
dberlin added a comment to D39025: [GVNSink] Fix failing GVNSink tests in the reverse iteration bot.

This seems reasonable to me,
I'd just add a comment to explain why it's a small set vector (so nobody breaks this future)

Oct 23 2017, 11:15 AM

Oct 22 2017

dberlin added a comment to D39011: [SimplifyCFG] try harder to forward switch condition to phi (PR34471).

So, in the original test and code it's hard to tell, but yes, if it's trying to undo the propagation of constants into phi nodes, it's already going to be fighting, because everything else is trying to do that transform specifically :)

Oct 22 2017, 11:04 AM
dberlin added a comment to D39011: [SimplifyCFG] try harder to forward switch condition to phi (PR34471).

Hey Sanjay,
GVN/NewGVN/et al will undo this transform, and propagate constants. In fact, i expect pretty much any pass that can, will.

Oct 22 2017, 10:06 AM

Oct 20 2017

dberlin added a comment to D38806: DepthFirstIterator.h: Use C++11 features to call a completed method onthe set type, instead of requiring that one exists..

I'll add a unit test.

Oct 20 2017, 12:01 PM
dberlin added inline comments to D38806: DepthFirstIterator.h: Use C++11 features to call a completed method onthe set type, instead of requiring that one exists..
Oct 20 2017, 11:22 AM
dberlin updated the diff for D38806: DepthFirstIterator.h: Use C++11 features to call a completed method onthe set type, instead of requiring that one exists..
  • Update for review comments
Oct 20 2017, 11:22 AM

Oct 18 2017

dberlin added a comment to D38806: DepthFirstIterator.h: Use C++11 features to call a completed method onthe set type, instead of requiring that one exists..

I haven't heard any better approaches yet, but i'll give a week before committing this.

Oct 18 2017, 8:03 PM

Oct 17 2017

dberlin added a comment to D38944: [GVN] Handle removal of first implicit CF instruction correctly.

"Even if we mark for deletion, we should update the map immediately to be able to hoist across the marked instruction. Marking alone does not solve the problem, it will still need the same code that also updates the map. If marking is only needed for uniformity of GVN code, this can be done separately from fixing the actual bug."
The instructions will be deleted and the map updated as soon as we return from this function up the call stack.
It will not prevent further anything, because

  1. the hoisting has already happened (and all the functions in this stack are going to return and then the next thing that will happen is we will delete the dead instructions)
  2. The marked instruction could not have blocked hoisting anyway, or else it would not have been safe to PRE.
Oct 17 2017, 9:25 AM
dberlin added a comment to D38944: [GVN] Handle removal of first implicit CF instruction correctly.

Both of the deletions are in PRE, after it has been successful. If either the inserted or the deleted instructions were implicit control flow, PRE should have been unsafe. It's probably worth noting this in a comment

Oct 17 2017, 8:00 AM

Oct 16 2017

dberlin added inline comments to D38944: [GVN] Handle removal of first implicit CF instruction correctly.
Oct 16 2017, 11:10 PM
dberlin added inline comments to D38944: [GVN] Handle removal of first implicit CF instruction correctly.
Oct 16 2017, 7:37 AM

Oct 13 2017

dberlin accepted D37353: [SparsePropagation] Enable interprocedural analysis.

Implement the previously discussed approach using generic LatticeKeys. A few things to note about this version of the patch:

First, there's a requirement that LatticeKeys are able to be the key_type of whatever mapping structure the generic solver uses internally (i.e., DenseMap). If a client uses a non-trivial type for LatticeKey, it will have to provide a specialization of DenseMapInfo. But we already have specializations for pointers and PointerIntPairs, which I think probably covers most potential clients. I've added a comment at the top of AbstractLatticeFunction mentioning this.

Oct 13 2017, 7:59 PM
dberlin added a comment to D37460: [GVN] Prevent LoadPRE from hoisting across instructions that don't pass control flow to successors.

I attached a patch for this to PR 34937.
I don't have time ATM to perform testing and shepherding of it through review, however.

Oct 13 2017, 5:48 PM
dberlin added a comment to D37460: [GVN] Prevent LoadPRE from hoisting across instructions that don't pass control flow to successors.

This is use after free.
When the first implicit control flow instruction for a bb gets erased, we now have wrong info.

Oct 13 2017, 5:38 PM

Oct 12 2017

dberlin added inline comments to D38856: [IPSCCP] Remove calls without side effects.
Oct 12 2017, 10:12 PM

Oct 11 2017

dberlin added a comment to rL313701: Revert "[GVNSink] Remove dependency on SmallPtrSet iteration order.".

I do not plan to address these at the moment, because the order is consistent in the pass and doesn't affect correctness or what gets optimized.
If someone else wants to try to make everything reverse order clean, they are welcome to, it's not a priority for me.

Oct 11 2017, 11:26 AM
dberlin added a comment to rL313701: Revert "[GVNSink] Remove dependency on SmallPtrSet iteration order.".

Yes, this is known. The original "fix" this reverts is clearly broken. There is a discussion on the original revert thread about this and ways to fix it properly.

Oct 11 2017, 11:19 AM
dberlin created D38806: DepthFirstIterator.h: Use C++11 features to call a completed method onthe set type, instead of requiring that one exists..
Oct 11 2017, 9:42 AM

Oct 10 2017

dberlin added a comment to D37353: [SparsePropagation] Enable interprocedural analysis.

This actually sounds like a great idea, IMHO.
Let's try it and see how well it works in practice.
It certainly would address my current concerns.

Oct 10 2017, 10:40 PM
dberlin accepted D37638: [IPSCCP] Move common functions to IPOUtils (NFC).
Oct 10 2017, 10:38 PM
dberlin accepted D38765: Don't replace constants with constants in GVN.

Okay if you address the remaining comments.
Thanks!

Oct 10 2017, 8:58 PM
dberlin added inline comments to D38765: Don't replace constants with constants in GVN.
Oct 10 2017, 8:56 PM
dberlin added a comment to D38765: Don't replace constants with constants in GVN.

Suggesting a slightly different fix.

Oct 10 2017, 6:00 PM
dberlin added a comment to D36656: [SCCP] Propagate integer range info for parameters in IPSCCP..

I suspect at least one of your bugs is that the param state lattice doesn't get updated when the value state lattice changes.

Oct 10 2017, 10:51 AM

Oct 9 2017

dberlin added a comment to D38569: Expose must/may alias info in MemorySSA..

I'd reuse the type we already have to express alias results.
While you don't care about partial alias, it makes all code have the same meaning for the same thing :)

Oct 9 2017, 7:04 PM
dberlin added a comment to D37353: [SparsePropagation] Enable interprocedural analysis.

(I think this needs a little thought)

Oct 9 2017, 1:30 PM
dberlin added inline comments to D37353: [SparsePropagation] Enable interprocedural analysis.
Oct 9 2017, 1:30 PM
dberlin added a comment to D37638: [IPSCCP] Move common functions to IPOUtils (NFC).

So, i can't find what the suggestion was, but these are fairly specific to value lattices and don't belong being used by most other things.
There are lattices where they are correct, and lattices where they make no sense.
It's also kinda conservative.

Oct 9 2017, 1:27 PM
dberlin accepted D37355: Add CalledValuePropagation pass.

thanks for working through this :)

Oct 9 2017, 11:26 AM
dberlin accepted D36656: [SCCP] Propagate integer range info for parameters in IPSCCP..

Sounds reasonable to start with.

Oct 9 2017, 11:10 AM
dberlin added inline comments to D36656: [SCCP] Propagate integer range info for parameters in IPSCCP..
Oct 9 2017, 7:25 AM
dberlin added a comment to D37355: Add CalledValuePropagation pass.

Also, if you used sets, you could just use set.swap in the constructor (or move constructors) to avoid the extra copying.

Oct 9 2017, 6:51 AM
dberlin added a comment to D37355: Add CalledValuePropagation pass.

I'm a bit confused why you use a vector instead of std::set or DenseSet. It looks like either would be better in every way?

Oct 9 2017, 6:50 AM

Oct 7 2017

dberlin added a comment to D38586: SLPVectorizer.cpp: Ensure SLPVectorizer can visit each block by dominated order.

Preds will in fact be thousands sometimes with switch statements. If you don't want to fix it, let me know and I'll fix the sort on Monday

Oct 7 2017, 7:37 AM

Oct 6 2017

dberlin added inline comments to D38569: Expose must/may alias info in MemorySSA..
Oct 6 2017, 7:56 AM

Oct 5 2017

dberlin added a comment to D37467: Add a new pass to speculate around PHI nodes with constant (integer) operands when profitable..

I've taken some time to go through the code in NewGVN that computes similar things based on the suggestion from Danny. These now do *very* similar things in terms of walk. The differences I've seen are:

  1. While the safety checks are both preorder, my code uses DFS instead of BFS. The reason is that we walk up the stack to mark more nodes as unsafe when we discover an unsafe node.
Oct 5 2017, 6:34 PM
dberlin requested changes to D38586: SLPVectorizer.cpp: Ensure SLPVectorizer can visit each block by dominated order.

Also this needs a test

Oct 5 2017, 3:07 PM
dberlin added a comment to D38586: SLPVectorizer.cpp: Ensure SLPVectorizer can visit each block by dominated order.

We sort siblings by RPO in newgvn. If you want to guarantee parent before child, however, just sort by the dominator tree dfs in and out numbers.

Oct 5 2017, 3:01 PM

Oct 4 2017

dberlin added inline comments to D38569: Expose must/may alias info in MemorySSA..
Oct 4 2017, 6:30 PM
dberlin added a comment to D37343: [CGP] Merge empty case blocks if no extra moves are added..

(Gonna let jakub comment on what should work/not work here)

Oct 4 2017, 4:20 PM
dberlin accepted D38561: [SparsePropagation] Move member definitions to header (NFC).
Oct 4 2017, 2:06 PM
dberlin added a comment to D38561: [SparsePropagation] Move member definitions to header (NFC).

LGTM

Oct 4 2017, 2:05 PM
dberlin accepted D38541: [Dominators] Take fast path when applying <=1 updates.
Oct 4 2017, 10:09 AM
dberlin added a comment to D38541: [Dominators] Take fast path when applying <=1 updates.

This looks right to me, since people were trying to do it anyway :)

Oct 4 2017, 10:09 AM

Oct 3 2017

dberlin added a comment to D38476: Template the sparse propagation solver instead of using void pointers.

Ah, the joy of not having users to break.
Yes, i expect you will have to move a bunch if not all of these to the header.

Oct 3 2017, 1:09 PM

Oct 2 2017

dberlin added a comment to D37353: [SparsePropagation] Enable interprocedural analysis.

FYI: I'm about to rename getOrInitValueState to getValueState.
That is what SCCP calls it, and IMHO, we should be consistent.

Oct 2 2017, 4:08 PM
dberlin created D38476: Template the sparse propagation solver instead of using void pointers.
Oct 2 2017, 1:26 PM
dberlin added a comment to D37353: [SparsePropagation] Enable interprocedural analysis.

It's worth noting: You can make propagation much faster by keeping a separate worklist for overdefined , and prioritizing it over the normal one.
This will move things to overdefined as quickly as possible.
(Because anything meet overdefined is just about always overdefined).

Oct 2 2017, 11:38 AM
dberlin added a comment to D37355: Add CalledValuePropagation pass.

I see this review has been hanging around a while, so i'll take a stab at reviewing it.

Oct 2 2017, 11:19 AM
dberlin accepted D38331: [Dominators] Add DFS number verification.
Oct 2 2017, 10:51 AM