similar to: [LLVMdev] Compiler opt is turned off ?

Since a, b, and c are globals, how does the optimize *know* they are not used elsewhere (e.g. another module)? On Fri, Jan 4, 2013 at 7:49 AM, Somenath Chakraborty <some.chak at gmail.com>wrote: > Hello, > > I was trying to run few testcases and see how llvm optmizes different > scenarios. I have a small testcase like: > > > #include <stdio.h> > > >

Thanks for your reply. So, we don't do any "use" check (for globals variables) beyond a module scope. If so, it answers my question. On Fri, Jan 4, 2013 at 6:53 PM, Justin Holewinski < justin.holewinski at gmail.com> wrote: > Since a, b, and c are globals, how does the optimize *know* they are not > used elsewhere (e.g. another module)? > -------------- next part

I completely agree with you. The source code I wrote here has the main function and is a complete code. That's why I was expecting load/store analysis could have been incorporated across the module. Thanks. On Fri, Jan 4, 2013 at 10:43 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > I'm not sure what you mean by "use" check. > If you compile this with LTO and

I'm not sure what you mean by "use" check. If you compile this with LTO and multiple modules, and guarantee that you have the main function, yes, you could optimize this. In all other cases, it's not possible to eliminate any of the remaining loads or stores you see, because you have no guarantee about what else could read it. Heck, a conforming implementation of printf could

Hello, I have just started using llvm. I was trying to debug how *clang* generates IR for very simple C testcases (few assignments and if-condsitions). To get a hold on the basic functions, I put some break points on following functions but debugger *didn't stop*: llvm::BasicBlock::Create llvm::BinaryOperator::CreateAdd (design has binary op) llvm::Value::Value llvm::BranchInst::Create

I'm investigating a miscompilation bug ( http://llvm.org/bugs/show_bug.cgi?id=19823 ), but I've run into a problem: the output of the program is different when I compile the IR with clang compared to opt | llc | clang. Any clues on how to resolve this difference? $ ./opt -O1 19823.ll | ./llc | ./clang -x assembler - -o a.out ; ./a.out ; echo $? 1 $ ./opt -O2 19823.ll | ./llc | ./clang -x

Hello, I am facing an issue with a small test where there is a chance that sign-extension is not introduced as expected - #include <stdio.h> void func( long x ) { printf(" %ld \n", x); } int main() { char c = -1; func ( c ); // c is zero extended to x return 0; } generated IR - define i32 @main() #0 { ........ store i8 -1, i8* %c, align 1 %2 = load i8,

On 20 Aug 2013, at 08:23, 王振江 <cryst216 at gmail.com<mailto:cryst216 at gmail.com>> wrote: A GlobalValue was declared and mapped to the variable p. Some LLVM IR instructions were created according to those generated by LLVM from source. I.e., load p, load a[1] based on p, load p again, store a[2] based on p, etc. The machine code turned out to be slightly optmized, as shown on the

Hi Brent, Looking at your code I can see at least one reason why some of the store operations remain in the output since you are (through x, y, and z) writing in memory which exists outside of your function (p). Constant propagation also seems to work in the first few lines, *y = *x +1 (%3) is stored directly. The strange thing to me is that the same doesn't happen for *z = *x + 2. Here

Hi Roel, the code you list below is precisely what I expect to get (of course the stores must happen but the constant folding should happen as well). It all looks very strange. LLVM is behaving as if the __restrict__ keyword was not used at all. Even more strange is the fact that for this function: double f(double *__restrict__ x, double *__restrict__ y, double *__restrict__ z) { *x = 1.0;

Hi Brent, I think this is a problem in the easy-cse transform. In this transform load operations can be replaced by their subexpression, in this case the propagated constant, based on the value of the 'CurrentGeneration' of memory writes. This implies that any store operation invalidates the knowledge about previously stored subexpressions. In general, this is a safe assumption but

I have no clue, I didn't have time to look into that example yet. How does the IR (before optimization) differ from the other version? Roel On 01/24/2012 04:45 PM, Brent Walker wrote: > Can you explain please why it works for this version of the function: > > double f(double *__restrict__ x, double *__restrict__ y, double > *__restrict__ z); > > What is different here?

Hi LLVMers, I would like to ask a question regarding aliasing. Suppose I have the following program: double f(double** p ) { double a,b,c; double * x = &a; double * y = &b; double * z = &c; *x = 1; *y = *x + 2; *z = *x + 3; return *x+*y+*z; } LLVM can tell that the three pointers do not alias each other so can perform the constant folding at compile time.

Peter Cooper wrote: > I think the problem here is that the IR doesn't have any way to attach restrict information to loads/stores/pointers. I think we do now, actually. Now that the loads and stores have TBAA metadata, I think the restrict attribute can go there. It needs to be attached to every use of a restrict pointer, but that's similar to how TBAA already works. > It works

I think the problem here is that the IR doesn't have any way to attach restrict information to loads/stores/pointers. It works on arguments because they can be given the 'noalias' attribute, and then the alias analyzer must understand what that means. Pete On Jan 24, 2012, at 7:47 AM, Roel Jordans wrote: > I have no clue, I didn't have time to look into that example yet.

Can you explain please why it works for this version of the function: double f(double *__restrict__ x, double *__restrict__ y, double *__restrict__ z); What is different here? There are stores here as well. Brent On Wed, Jan 25, 2012 at 12:34 AM, Roel Jordans <r.jordans at tue.nl> wrote: > Hi Brent, > > I think this is a problem in the easy-cse transform. In this transform

TBAA Question. Please consider the following test case. ---Snip-- struct B { int b1; int b2; }; struct C { int b1; }; struct A { int a1; struct C SC; int a2; }; int foo1(struct A * Aptr, struct B* Bptr) { int *a = &Aptr->SC.b1; *a=10; Bptr->b1 = 11; return *a; } int foo2(struct A * Aptr, struct B* Bptr) { Aptr->SC.b1=10; Bptr->b1 = 11; return

Hi I do not really understand why frontend generated TBAA metadata is needed for the TBAA pass to work. It seems to me that we can always go up the IR chain and find the base type from which the pointer is derived from. Take the following example. I know %0 = load i32, i32* %a, align 4, !tbaa !1 and store i32 %i.02, i32* %b, align 4, !tbaa !6 do not alias as their metadata !1 = !{!2, !3, i64

I found a something that I quite not understand when compiling a common piece of code using the -Os flags. I found it while testing my own backend but then I got deeper and found that at least the x86 is affected as well. This is the referred code: char pp[3]; char *scscx = pp; int tst( char i, char j, char k ) { scscx[0] = i; scscx[1] = j; scscx[2] = k; return 0; } The above gets

To reproduce the issue, please use the command line "opt -simplifycfg filename". target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-unknown-linux-gnu" %struct.G = type { %struct.ordered_index_node*, i32 } %struct.ordered_index_node = type { %struct.B, %struct.F } %struct.B = type { i32 } %struct.F = type { i32*, i32* }