similar to: [LLVMdev] Books, papers and information

Hi all Is there any systematic way to compute all possible paths, first-order loops and j-th order loops between two given nodes in a flowgraph (directed graph with cycles) - preferably using the igraph library in R? I have checked the igraph documentation but I can't figure out any direct and systematic way to do so. Any ideas? I use the following definitions from Butler, R. and A.

On Jan 6, 2012, at 8:27 PM, Daniel Berlin wrote: > Note: GCC takes exactly the same approach as LLVM here, for exactly > the reason chris specifies. > In fact, until we started local SSA updating (which is now many years > ago, but ...), dominance frontier calculation for ssa updating was in > the top 10 profile functions for GCC compiles of large source files. > I had tried a

On Fri, Jan 6, 2012 at 8:17 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jan 6, 2012, at 5:08 PM, Chris Lattner wrote: > >>>> >>>> It's very like SSA construction, but must make provision >>>> testing anti dependences.  I had planned to use dominance frontiers to >>>> guide placement of phi nodes, as usual. >>>

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

Hi folks, For the past month I’ve been working on improving the DominatorTree and PostDominatorTree in LLVM. The RFC that explains the motivations and plans can be found here: http://lists.llvm.org/pipermail/llvm-dev/2017-June/114045.html . Here’s a short summary of what changed upstream since posting it: - We switched from the Simple Lengauer-Tarjan algorithm for computing dominators

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

Consider the following C code. When it is compiled using clang with ' -O', the assert fires. Gcc seems to do the opposite. #include <assert.h> int main() { unsigned a; // uninitialized! unsigned b = a; assert(b == a); // shouldn't this be always true? return 0; } Would you consider this a LLVM bug? I think GVN is responsible for this. I don't know if it

On Sat, Jan 7, 2012 at 12:14 AM, Cameron Zwarich <zwarich at apple.com> wrote: > On Jan 6, 2012, at 8:27 PM, Daniel Berlin wrote: > > Note: GCC takes exactly the same approach as LLVM here, for exactly > the reason chris specifies. > In fact, until we started local SSA updating (which is now many years > ago, but ...), dominance frontier calculation for ssa updating was in

Hi, this is the fourth in a series of patches to cleanup and improve the LLVM Profiling Infrastructure. It depends on the previous patches from http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-July/023569.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-July/023602.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-July/023642.html This patch introduces an implementation of the ProfileInfo

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, > >

I'm very interested in seeing support for stack/context switching in LLVM, if only for prototyping language ideas. I'm particularly interested in mechanisms that would make it possible to implement full asymmetric coroutines as described in "Revisiting Coroutines" (Moura & Ierusalimschy, Feb 2009 TOPLAS). From skimming the thread and looking at the llvm-stack-switch wiki, it

Here's how I did things, back when I got to write my own infrastructure. It's still O(n^2) in the worst case, but *much* quicker in the expected case. Number all the basic blocks, 0 to n-1 and build a vector mapping from integer to block. Requires O(n) time and space. For each block, compute the set containing it's dominance frontier, based on Figure 10 of * * *Efficiently

After running through bugpoint, I get this reduced function You can reproduce the problem with: opt bugpoint-reduced-function.bc -break-crit-edges -adce -verify Bugpoint is currently trying to narrow down which block breaks this, but is so far failing. It seems to be running out of memory rather than failing on a particular block. This is on freebsd 5.4, X86, llvm is compiled with gcc 3.4.2

Please take a look: http://llvm.org/docs/ReleaseNotes.html -Chris -- http://nondot.org/sabre/ http://llvm.org/

Chris, Here's my review notes: 1. In the Known problems section you identify PR656 as a known problem. However, this bug is resolved and in January you reported that you verified it on Solaris. So, one of two things needs to happen. Either remove this item from the release notes, or re-open the bug and tell me what still breaks. 2. It seems that several items from the original DRAFT email

On Mon, Apr 12, 2010 at 6:15 AM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > I created a wiki at http://code.google.com/p/llvm-stack-switch/ > > Right now I just copied and formatted the document as-is... I'll go > back over it with your comments in mind soon.  One more question, > which you can answer here or there: > >> Point 4 is a bit confusing.

Hi Everyone, Here are my notes on the LLVM 1.7 release, which will go into the final release announcement. As Tanya mentioned, it has been far too long since the last release, and there have been a lot of CVS commits since Novemeber. :) I went through them all and pulled out some of the major improvements, which I've listed below. I'm certain that I have forgotten some things, so

Hi Daniel, Thanks a lot for all these explanation, I will try it out. Hongbin On Tue, Apr 25, 2017 at 7:04 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Tue, Apr 25, 2017 at 6:42 PM, Hongbin Zheng <etherzhhb at gmail.com> > wrote: > >> >> >> On Tue, Apr 25, 2017 at 6:32 PM, Daniel Berlin <dberlin at dberlin.org> >> wrote:

A while ago I reported a bug in the computation of the post-dominance frontier (PDF). I submitted it as http://llvm.org/bugs/show_bug.cgi?id=1069, and it is now marked as a duplicate of http://llvm.org/bugs/show_bug.cgi?id=1098, which is still an open bug. I needed the PDF to compute control dependencies for code on which I'm working. I was not familiar with the algorithm used in LLVM

Feedback below.. > <will insert overview blurb here> Big new things: llvm-gcc4, new sparc > backend, Generic vector/SSE/Altivec support, X86 Scalar SSE support, > debugging support, many target-independent codegen improvements, inline asm, > llvm.org/web-reg. > > > Core LLVM IR Improvements: > > * The LLVM IR now has full support for representing