similar to: [LLVMdev] For alias analysis, It's gcc too aggressive or LLVM need to improve?

> your C program invokes undefined behavior when it dereferences pointers that > have been converted to other types. See for example > http://stackoverflow.com/questions/4810417/c-when-is-casting-between-pointer-types-not-undefined-behavior I don't think it's quite that simple.The type-based aliasing rules come from 6.5p7 of C11, I think. That says: "An object shall have

+aliasing people I *think* this is valid, because the rules have always been described to me in terms of underlying storage type, and not access path. These are all ints, so all loads and stores can alias. On Sat, Aug 9, 2014 at 3:07 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Tim Northover" <t.p.northover at gmail.com>

I'll take this from the C++ angle; the C rules are not the same, and I'm not confident they give the same answer. On Mon, Aug 11, 2014 at 2:09 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > The access path matters (in some sense), but this is, AFIAK, valid no > matter how you look at it. > > Let's take a look line by line > > #include <stdio.h> >

On Mon, Aug 11, 2014 at 11:44 PM, Kevin Qin <kevinqindev at gmail.com> wrote: > Hi all, > > Thanks for you paying time to look at this issue. I'm not an expert for > C/C++ language, so I can just post some experiment results from LLVM and > GCC. > > If we make minor changes to the test, gcc may give different results. > > #include <stdio.h> > struct

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:

Jianzhou Zhao <jianzhou <at> seas.upenn.edu> writes: > At this level, I can understand how it works. I was confused because I > have been looking at the source code for implementing them. All the > globalmodref, scev-aa, steenaa and ds-aa are only subclasses of the > AliasAnalysis class, so I cannot see how ds-aa can automatically call > basicaa. There's some magic

On Wed, Jan 4, 2012 at 12:10 PM, David Gardner <daveg at xmos.com> wrote: > Jianzhou Zhao <jianzhou <at> seas.upenn.edu> writes: >> The documents say that all the aa analysis are chained, and give an >> example like opt -basicaa -ds-aa -licm. In this case, does ds-aa >> automatically call basicaa for the case when ds-aa can only return >> MayAlias? This

Hi there, I am trying to understand how AliasAnalysis works out in LLVM. I used the following simple test-case (test4.c): -- void test() { int *jj, *kk; int aa = 100; jj = &aa; *jj = 300; } int main() { test(); return 0; } -- Then I did "llvm-gcc -emit-llvm -c -o test4.bc test4.c" to get bc. I tried the following 2 ways to get what I expect to get as

On 2009-06-29 11:16, Wenzhi Tao wrote: > Hi, all > > According to the document "LLVM Alias Analysis Infrastructure", I > evaluated the AA performance by using the paramenters '-basicaa -ds-aa > -anders-aa'. The source code 'test.c' is listed as follow: > [...] > The whole process: > > llvm-gcc -emit-llvm -O0 -c test.c -o test.bc > > opt

Jianzhou Zhao <jianzhou <at> seas.upenn.edu> writes: > The documents say that all the aa analysis are chained, and give an > example like opt -basicaa -ds-aa -licm. In this case, does ds-aa > automatically call basicaa for the case when ds-aa can only return > MayAlias? This looks magic to me. Is this handled by AnalysisGroup > magically? As I understand it, the

On Thu, May 14, 2009 at 2:19 PM, Weihua Sheng <weihua.sheng at gmail.com> wrote: > I actullay would expect the more accurate results from applying > anders-aa, but I could not interpret what has been returned - at least > I should see something like jj->aa, right? I'm not quite following... jj and aa don't alias; both versions show that. The results returned for

Hi, I am using LLVM 2.4 on a Linux RHEL5 machine. I was trying to figure out how the chaining of the alias analysis passes works in LLVM. Here are the command I used to test the chaining part. 1. ./opt hello_world_1_nest_func.bc -o hello_world_1_nest_func_AA.bc -no-aa -anders-aa -licm Result: Anderson's AA and No Alias Analysis both are called. 2. ./opt hello_world_1_nest_func.bc -o

dirac wrote: > Hi, > I am using LLVM 2.4 on a Linux RHEL5 machine. I was trying to figure > out how the chaining of the alias analysis passes works in LLVM. Here > are the command I used to test the chaining part. > 1. ./opt hello_world_1_nest_func.bc -o hello_world_1_nest_func_AA.bc > -no-aa -anders-aa -licm > Result: Anderson's AA and No Alias Analysis both are

On Tue, Jan 3, 2012 at 4:55 PM, Chris Lattner <clattner at apple.com> wrote: > On Jan 3, 2012, at 1:53 PM, Jianzhou Zhao wrote: >> I see. I asked the question because LLVM provides several alias >> analysis, and I was wondering how to decide which one should be used >> for compiling most programs. >> >> I think the basicaa is the default one, but by looking

Hi Eli, thanks for the answers helping out. I tried to understand further - got another example: void test() { int *jj, *kk; int aa = 100; jj = &aa; *jj = 300; kk = jj; *kk = 400; } int main() { test(); return 0; } bc looks like the following (only test() part) define void @test() nounwind { entry: %aa = alloca i32 ; <i32*> [#uses=2] %kk =

On Wed, Nov 24, 2010 at 2:50 PM, Nick Lewycky <nicholas at mxc.ca> wrote: > The AA that you specify will be created when you specify it and live > until that pass is invalidated (not explicitly preserved by a pass that > runs). The next time a pass requires AA, the pass manager will create > the default AA (BasicAA) and not the one you put on the command line. > I thought

On Monday 25 April 2005 14:43, Vladimir Prus wrote: > The 'i' variable is never modified in the program, however, all analyses > except for -globalsmodref-aa report that the > > %tmp.3 = call int %_Z3bari( int %p ) ; <int> [#uses=1] > > instruction can modify 'i'. I'm somewhat surprised, because it looks like > -globalsmodref-aa is the simplest

Kenneth Uildriks wrote: > On Wed, Nov 24, 2010 at 2:50 PM, Nick Lewycky<nicholas at mxc.ca> wrote: > >> The AA that you specify will be created when you specify it and live >> until that pass is invalidated (not explicitly preserved by a pass that >> runs). The next time a pass requires AA, the pass manager will create >> the default AA (BasicAA) and not the

Hello everyone, If you've read through my previous introduction email (http://lists.llvm.org/pipermail/llvm-dev/2016-May/099573.html), you can safely ignore this message. The short story is: CFL-AA does not seem to be broken anymore. Please try it out and help us find more bugs / performance issues if switching to it in the future sounds interesting to you. Here are more backgrounds: I

Hi, I'm writing a custom alias analyser for the Glasgow Haskell Compiler's LLVM backend to teach LLVM that our explicitly-represented stack cannot alias with any heap pointer. It works, but I've hit an issue with opt's handling of alias analysers; if you specify -ghc-aa on the opt command line then LLVM only uses that analyser until (I think) a pass runs that invalidates the