search for: dominance

Hi Tobias, 1) Daniel and Chandler have for a long time been talking about computing > dominance and post-dominance in one shot to reduce the cost of > post-dominance and make it (freely) available everywhere. Is this > covered by your current (or planned) work? I'm not sure what you exactly mean by one shot; I'll ask around tomorrow. I wanted to play a little bit with your...

...FromEntry(DefBB)) > return false; > > > > Riddle me this: If unreachable definitions dominate nothing, how are > unreachable uses always dominated by their unreachable defs? I think the comment is just just missing an "otherwise" at the start. If we were to define dominance rules as you suggest, we would still accept define void @f() { bb0: ret void bb1: %a = getelementptr inbounds i8* %b, i64 1 ret void bb2: %b = getelementptr inbounds i8* %a, i64 1 ret void } Since bb1 dominates bb2 and bb2 dominates bb1, no? It looks like a case where we would just be...

Hi Henrique, I have tried using -mergereturn and inserting a free into the predecessors of dominance frontier of malloc block and it caused double free. It is possible for multiple free's to be inserted on the path from malloc to an exit. For example, in the following CFG: BB10 (malloc) / \ BB11 BB12 ... / \ / \...

Try breaking the critical edges (-break-crit-edges). This way, a new block will be created between BB13 and BB11 (call this BB11.break) and BB15 and BB12 (call this BB12.break). The predecessors of the dominance frontier will, thus, be BB11.break, BB12.break, and BB14. When we enter through a block with a call to malloc(), we will end up in one of the blocks in the dominance frontier (kind of). These blocks must have multiple predecessors, else it would not be in the dominance frontier. If a predecessors...

This is release_50 branch of git, sha1: f1d5723be3f9456a6b16cdf687847ac2918846de Using gcc 7.2.0 from homebrew. $ CC=/usr/local/opt/gcc/bin/x86_64-apple-darwin16.7.0-gcc-7 CXX=/usr/local/opt/gcc/bin/x86_64-apple-darwin16.7.0-g++-7 cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/Users/andy/local/llvm5 -DCMAKE_PREFIX_PATH=/Users/andy/local/llvm5 $ make VERBOSE=1 [ 92%] Linking CXX

Like I said, i'm nearly positive there is a much faster way, as the sets are mostly shared except in the cyclic case, and in all reducible cyclic cases, removal of back-arcs does not affect dominance (because in any reducible flowgraph, v dominates u whenever u,v is a back-arc) On Tue, Apr 25, 2017 at 7:38 PM, Hongbin Zheng <etherzhhb at gmail.com> wrote: > Hi Daniel, > > Thanks a lot for all these explanation, I will try it out. > > Hongbin > > On Tue, Apr 25, 20...

...decessors. >>>>> >>>> "For each predecessor" do you mean "For each predecessor of the basic >> blocks in the set"? I.e. for each predecessor of B and C in this example. >> > > No, for each predecessor of D. > > The definition of dominance is that d dominates n if every path from root > to n goes through d. > This means for anything to collectively dominate a node, it either must: > Be be in the idom tree (ie so that the above is definitely true) > or cover every path into the block. > > The only way to cover every...

Many published analyses which build on post-dominance assume a canonical single-dominator-tree form induced by unifying all exits (and often adding a virtual edge from START to END). In contrast, it seems that the current LLVM post-dominator analysis only operates in a mode in which it generates a forest of post-dominator trees, with one rooted at eac...

When looking into https://llvm.org/bugs/show_bug.cgi?id=24866, I discovered that the root cause of the crash is that I was expecting every basic block to have a corresponding Node in the dominator tree. Apparently, the "while.end" basic block in the example does not have a Node in the Dominator Tree. Can anyone tell me if this is expected? If so, under what circumstances?

Hi, In browsing through the LLVM source, I don't currently see an implementation for a control dependence graph builder. Am I overlooking something? It doesn't look like LLVM currently provides a way to build the post-dominance frontier of the reverse CFG, either. Dominators.h mentions forward dominators, but I believe all this is referring to is dominators as opposed to post-dominators, not dominators on the CFG versus dominators on the reverse-CFG. I just wanted to make certain I'm not overlooking anything before I...

...la at gmail.com> wrote: >> >> > Maybe. >> > My view is the ideal is either no-unreachable code, or unreachable >> > blocks >> > only contain terminators. >> >> I am definitely happy with both. What worries me is introducing a >> special dominance rule for unreachable blocks. >> >> >> I don't think that rejecting >> >> >> >> %a = getelementptr inbounds i8* %a, i64 1 >> >> >> >> but accepting >> >> >> >> %a = getelementptr inbounds i8* %b, i64 1...

...//pdfs.semanticscholar.org/cbb2/9a0e4895025bd9df24f9263217df12f1ed1e.pdf I think a great outcome of your internship would be some precise documentation regarding the guarantees the LLVM dominators give -- possibly also considering classic and weak control dependence and the difference between loop-dominance and dominance. Please keep me up-to-date with your work. This is really work that has long been overdue! Best, Tobias On Tue, Jun 13, 2017, at 10:23 AM, Tobias Grosser via llvm-dev wrote: > On Tue, Jun 13, 2017, at 09:22 AM, Jakub (Kuba) Kuderski via llvm-dev > wrote: > > Tobias, &gt...

Hi I run into an issue as part of splitting a critical edge during LICM. When a new basic block is created and needs to be added into the dominator tree, the block is already in the dominator tree. I print the dominator tree and I see it is added into the tree as child of node it is supposed to dominate. How do I debug to find out why/when its getting added into the tree. ? Tips/suggestions on

There is PostDominatorTree for determining post-dominance. Even if A post-dominates B and B is executed, that doesn't guarantee that A will be executed. For example, there could be an infinite loop in-between. Strong post-dominance makes the stronger guarantee that there will be no infinite loop from B to A. Do we have anything in LLVM for determining...

On Tue, Apr 25, 2017 at 6:32 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Tue, Apr 25, 2017 at 6:17 PM, Hongbin Zheng <etherzhhb at gmail.com> > wrote: > >> Hi Daniel, >> >> I mean "*As a set*, B + C dominate D". >> >> On Tue, Apr 25, 2017 at 5:42 PM, Daniel Berlin <dberlin at dberlin.org> >> wrote:

...< henrique.nazare.santos at gmail.com> wrote: > PRE normally uses a latest placement algorithm to do something of the sort. > I don't know about GVN/PRE, but older version of PRE might have it. > Just placing the calls to free at the predecessors (dominated by BB12) of > the dominance frontier of BB12 seems to work, however. Is there anything > wrong with this? > It seems that placing the calls to free at the predecessors of dominance frontier is inadequate. It is possible that there are exit blocks that are dominated by BB12 (calls to malloc). I guess we can also insert c...

> > It seems that placing the calls to free at the predecessors of dominance > frontier is inadequate. It is possible that there are exit blocks that are > dominated by BB12 (calls to malloc). I guess we can also insert calls to > free at these exit blocks too. That crossed my mind a few minutes later. : ) If you're interested, PRE.cpp existed last at r25315....

Hi, Is there any way to quickly test if a set of basic block collectively dominate another basic block? Thanks Hongbin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170425/b9336a6d/attachment.html>

Hi folks, This summer I'm working on improving dominators during my internship at Google. Below is an RFC on switching to dynamic dominators, which you can also read as a Google Doc <https://docs.google.com/document/d/1wPYeWykeO51YDPLYQEg4KNTlDIGIdyF65OTfhSMaNHQ/edit?usp=sharing> if you prefer so. Please let us know what you think. ~Kuba

On Aug 24, 2009, at 4:58 PM, Jonathan Ragan-Kelley wrote: > Many published analyses which build on post-dominance assume a > canonical single-dominator-tree form induced by unifying all exits > (and often adding a virtual edge from START to END). In contrast, it > seems that the current LLVM post-dominator analysis only operates in a > mode in which it generates a forest of post-dominator trees, wi...