similar to: [LLVMdev] alias analysis library

Hi Daniel, On 03/21/2016 11:05 AM, Daniel Berlin wrote: > > > On Tue, Mar 15, 2016 at 1:37 PM, Jia Chen via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Dear llvm devs, > > tl;dr: What prevents llvm from switching to a fancier pointer > analysis? > > > Nothing. > > > Currently,

Hi Christian, Thank you so much for the reply! Please see my comments inline. On 03/21/2016 09:32 AM, Christian Convey wrote: > Hi Jia, > > If one looks at existing research literatures, there are even more > algorithm to consider for doing pointer analysis. > > > For at least some published AA algorithms, there may be some > uncertainty about software patents

Dear llvm devs, tl;dr: What prevents llvm from switching to a fancier pointer analysis? Currently, there exists a variety of general-purpose alias analyses in the LLVM codebase: basic-aa, globalsmodref-aa, tbaa, scev-aa, and cfl-aa. However, only the first three are actually turned on when invoking clang with -O2 or -O3 (please correct me if I'm wrong about this). If one looks at

On Sun, Mar 12, 2017 at 2:55 PM, Oliver Braunsdorf via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > Perhaps by "value" you mean points-to set? > > Thats right! I meant the points-to set. Sorry I didn't mention that. > I want to track back the value of the parameter to its definition -- an > "assignment" which could be indirect through a pointer

Hello, I'm playing with alias analysis, using the following program: %i = external global int ; <int*> [#uses=2] implementation ; Functions: int %_Z3bari(int %p) { entry: %tmp.0 = load int* %i ; <int> [#uses=1] %tmp.1 = setgt int %tmp.0, 10 ; <bool> [#uses=1] br bool %tmp.1, label %then, label %UnifiedReturnBlock then:

Hi, I wrote a module pass that uses Alias Analysis. For this reason I added AU.addRequired<AliasAnalysis>() to function getAnalysisUsage and used getAnalysis<AliasAnalysis>() in my pass. I tried a few types of alias analyses and I discovered that only alias analyses which are ImmutablePasses are returned using getAnalysis<AliasAnalysis>(). Moreover, when I added both

On Mon, Jun 15, 2015 at 4:54 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > I'm mostly going from Robert Wilson's 1997 phd thesis, although I'm > pretty > > sure I've seen a lot of the same ideas elsewhere as well. > > Yes, using summary/transfer functions has been tried a lot. > Note: the numbers in most of these phd thesis do *not* get born

On Mar 21, 2016, at 10:00 AM, Jia Chen via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> So my question here is: what kind(s) of precision really justify the cost and what kinds do not? >> >> Depends entirely on your applications. >> >> Has anybody done any study in the past to evaluate what kinds of features in pointer analyses will benefit what

Hi all, I'm a 3rd year CSE B.Tech student and have been studying LLVM since the past year. I have written a pass for doing register allocation as part of my course project and have also been studying LLVM code sections related to SSA construction, dominance frontiers,etc. I also made some contributions to the Polly project. Currently I am interested in improving the existing alias analysis

> It is merely a demand-driven way of implementing existing > analyses, by extending those algorithms to track additional > "pointed-to-by" information. Laziness may help with the running > time of the cfl analysis when only partial points-to info is > needed, but if the client wants to do a whole-program analysis and > require whole-program

Hi, I'm trying to optimize a simple C code and came across a situation where invariant code is not being moved out: On an -O3 compilation, I noticed that the "load" for the loop bounds (which remain invariant throughout) happens on each iteration of both the loops, even though it is not modified anywhere in the function "bigLoop". It seems that alias analysis is not able

Hi John, thanks for your feedback. I'll try to answer your comments bellow. On Mon, Apr 2, 2012 at 10:59 AM, John Criswell <criswell at illinois.edu> wrote: > On 3/30/12 7:07 PM, Douglas do Couto Teixeira wrote: >> >> Hi guys, >> >> I'm an undergraduate computer science student and I've been working >> with pointer analysis this semester under

Hi Xin, Thank you for your reply! I have tried the 3 alias analyses you have mentioned on LLVM 3.5: 1) $ opt -globalsmodref-aa -aa-eval < xxx.bc > /dev/null (May-alias response 100%) 2) $ opt -tbaa -aa-eval < xxx.bc > /dev/null (May-alias response 100%) 3) $ opt -cfl-aa -aa-eval < xxx.bc> /dev/null (Unknown command line argument '-cfl-aa') It seems that they are not

On Mon, Jun 15, 2015 at 3:29 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > On Mon, Jun 15, 2015 at 10:33 AM, Christian Convey > <christian.convey at gmail.com> wrote: > > On Mon, Jun 15, 2015 at 11:02 AM, Daniel Berlin <dberlin at dberlin.org> > wrote: > Which paper are you using? > I'm mostly going from Robert Wilson's 1997 phd thesis,

BTW, I have found why it doesn't work for arrays. TBAA information propagation is not implemented in CodeGenFunction::EmitArraySubscriptExpr with "TODO: Preserve/extend path TBAA metadata?". On Fri, Dec 4, 2015 at 1:38 PM, Dmitry Polukhin <dmitry.polukhin at gmail.com> wrote: > As far as I can see it is specifics of arrays inside structs. Current TBAA > does distinguish

Hi again! Replying in chronological order: > On Thu, Jul 9, 2020 at 6:51 PM Shuai Wang <wangshuai901 at gmail.com > <mailto:wangshuai901 at gmail.com>> wrote: > > Hey Matt, > > That's awesome. Thank you very much for all the information and > clarification! Just a few follow up questions. Could you kindly shed > some lights on it? Thank

Jeroen, thank you for very useful link with the context. Indeed union cases are very complicated and I see places in code when TBAA gives up. Daniel, I completely agree that TBAA has limited power and can solve relatively simple cases only. So anything more complicated that involves intermediate variables that points to struct or array elements cannot be solved by TBAA alone. Differentiating

Perhaps by "value" you mean points-to set? Either way, flow-sensitivity can only give you more precise -- but still not necessarily exact -- answers. Yours, Andrey === Compiler Architect NXP On Fri, Mar 10, 2017 at 6:39 PM, Flamedoge via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > For a given argument of a call instruction in the cfg: Where does the > value of

On Tue, Jan 3, 2012 at 3:54 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jan 2, 2012, at 9:42 PM, Jianzhou Zhao wrote: > >> Hi, >> >> Chapter 4 in http://llvm.org/pubs/2005-05-04-LattnerPHDThesis.html >> compares the precision of alias analysis in LLVM at that time. Does >> the latest LLVM still follow the similar results? I was also

I just wrapped up some fairly major changes to the AliasAnalysis infrastructure in LLVM, and thought LLVMdev should know about it. In particular, here are the highlights: 1. AliasAnalysis can now take into consideration the size of a memory access to determine whether or not something aliases. This is crucial for a field-sensitive analysis to not cause bad transformations to happen. 2.