similar to: [LLVMdev] embedded dataflow tracking code?

Is there a traditional dataflow algorithm buried in LLVM somewhere? I need to be able to do some very late transformations (after regalloc) and we aren't in SSA anymore. I will need a dataflow analysis to ensure correctness. At one point I thought I remembered seeing a generic fixed-point dataflow analysis engine but now I can't find it. Does it still exist or did it ever exist? If

On 4/16/13 11:30 AM, dag at cray.com wrote: > Is there a traditional dataflow algorithm buried in LLVM somewhere? I > need to be able to do some very late transformations (after regalloc) > and we aren't in SSA anymore. I will need a dataflow analysis to ensure > correctness. > > At one point I thought I remembered seeing a generic fixed-point > dataflow analysis engine

Hi I have just taken a look at the LLVM-compiler and i am trying to write a pass which analyses the dataflow and sideeffects. So far i have written my own pass which works and i can traverse the blocks, functions and instructions. Currently i am using the "runOnFunction" function and iterate over the functions and blocks. But this seems to be not optimal since the instructions

Hi all, I just found an optimization regression regarding simple dataflow/constprop analysis: https://godbolt.org/g/Uz8P7t This code ``` int dataflow(int b) { int a; if (b==4) a = 3*b; // fully optimized when changed to a = 3; else a = 5; if (a == 4) return 0; else return 1; } ``` is no longer optimized to just a "return 1". The regression happened in LLVM

Dear Shulin, Sounds like you'll need an inter-procedural analysis across different source files. One option I can think of is to manually update the Makefiles, make compiler emit bitcode files, merge them with llvm-link and run it through your optimization pass as a big bitcode file. This somehow could involve huge amount of tedious work for a huge project like Apache, and may be error-prone.

On Apr 16, 2013, at 10:27 AM, John Criswell <criswell at illinois.edu> wrote: > On 4/16/13 11:30 AM, dag at cray.com wrote: >> Is there a traditional dataflow algorithm buried in LLVM somewhere? I >> need to be able to do some very late transformations (after regalloc) >> and we aren't in SSA anymore. I will need a dataflow analysis to ensure >> correctness.

I came across this thread from a couple years ago: http://lists.llvm.org/pipermail/llvm-dev/2017-November/119346.html Has there been any progress on RDF for X86? Or is there some other preferred alternative for performing reachability analysis after register allocation? Thanks, Scott Constable -------------- next part -------------- An HTML attachment was scrubbed... URL:

While attempting to run DataFlowSanitizer for 32 bit target (-m32), I received the following error: unsupported option '-fsanitize=dataflow' for target 'i386-unknown-linux-gnu' Does it mean that DFSan doesn't support 32 bit memory model? -- Thanks & Regards, Dipanjan -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, Is there any way in LLVM to specify and solve dataflow equations? Thanks, Nilesh.

There are passes which mark function parameters as "nocapture", which means that the function does not store the passed-in pointer for use after that function returns. If pointers to a newly created object are only ever passed through "nocapture" parameters, never stored in a global, and not returned from the function, then that object is dead when the function that created

I am learning to do some basic dataflow analysis on C code projects, such as Apache httpd. Now I am a newbie of LLVM IR, and there are some problems in doing that. In the official User Manual of how to write a LLVM PASS, they only show the way to generate IR of a single ".c" source file. But in fact there are so many examples that the usage and definition of a function are not in the

As mentioned in the title, I want to do some control-flow and dataflow analysis. I can only find the assignment statement in a function, but the assigned variable is just a parameter of this function. For example, **************************************** int foo(struct A* a, int b, ...){ ... a->Int_field = b; ... return 0; } ***************************************** in the code

Andrew Trick <atrick at apple.com> writes: > David was asking for a post-register-rewrite analysis, which I think > is a totally different problem and best implemented separately by each > target. The target knows best which register units are overwritten or > preserved by an operation. We try to fake it with > undef/implicit-use/implicit-def, but it isn't reliable.

I'm working on an LLVM-based compiler for a very closure-centric language. It's becoming apparent that it's going to suffer heavily from garbage collector churn, as all the useful programming idioms the language makes possible are going to involve memory allocations, either to create objects or to allocate storage for upvalues. However, it's possible to optimise away a lot of heap

On Thu, Jul 6, 2017 at 7:00 AM, Davide Italiano <davide at freebsd.org> wrote: > On Wed, Jul 5, 2017 at 3:59 PM, Johan Engelen via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Hi all, > > I just found an optimization regression regarding simple > > dataflow/constprop analysis: > > https://godbolt.org/g/Uz8P7t > > > > This code >

On Jul 9, 2017 10:24 AM, "Daniel Berlin" <dberlin at dberlin.org> wrote: >> Matt Simpson and I briefly discussed this transformation. One of his > suggestions was to add a pass in the pipeline where the dominator tree was > available (note my patch used a poor man's version of domination) and to > add range meta-data to values (or replace values if we know the

On 7/7/2017 4:59 PM, Davide Italiano wrote: > On Fri, Jul 7, 2017 at 1:47 PM, Chad Rosier <mcrosier at codeaurora.org> wrote: >> David/Johan, >> >> I would love to claim victory, but I don't think that D34901 catches this >> case. >> > Hi Chad, thanks for taking another look at this. > Maybe I didn't bisect correctly. Apologies. Anyway, more fun

On Sat, Aug 28, 2010 at 10:53 AM, David Given <dg at cowlark.com> wrote: > On 28/08/10 02:20, Kenneth Uildriks wrote: >> There are passes which mark function parameters as "nocapture", which >> means that the function does not store the passed-in pointer for use >> after that function returns.  If pointers to a newly created object >> are only ever passed

On 29/08/10 16:28, Kenneth Uildriks wrote: [...] > Now the case where function A calls function B, and function B needs > to return a pointer to a freshly-allocated object, is fairly common. > One way to attack this is to have each function create its own > "region" or "memory pool" and destroy it when it returns. [...] > This > scheme will allow any call

David/Johan, I would love to claim victory, but I don't think that D34901 catches this case. However, I got interested and threw this together quickly: https://reviews.llvm.org/D35140. This does catch the below case. If people are interested I can add test cases and submit for formal review. FWIW, it does hit about 1/3 of all of the SPEC benchmarks. I haven't done any performance