similar to: [LLVMdev] Missing optimization in constant propagation?

On Fri, Jul 15, 2011 at 12:21 AM, Martin Apel <martin.apel at simpack.de> wrote: > Hi all, > > I stumbled across a peculiarity regarding constant propagation that I don't understand. I'm not sure, if I oversee anything or if it's a missing feature. > > I have created the following simple test function in C: > > int times_zero(int a) > { >  return (a *

Hi Duncan, thanks for the quick reply. I understand, that the generated code is different between the two approaches. But I would still expect IEEE rules to be respected in any case. I do not see any reason why -fPIC -fomit-frame-pointer and the like should have any impact on the results computed by the generated code. Are there any options I can set on the command line of llc to force the

Hi Martin, > thanks for the quick reply. I understand, that the generated code is different > between the two approaches. > But I would still expect IEEE rules to be respected in any case. I do not see > any reason why -fPIC -fomit-frame-pointer > and the like should have any impact on the results computed by the generated code. probably in the direct case you are using the x86

I am trying to implement loop unrolling in a context, where lots of constant propagation has taken place. Unrolling an outer loop might make an inner loop have constant bounds, therefore I want to process the loops outside in, i.e. from parent loops to nested loops. Unfortunately the standard loop pass manager performs loop passes inside out, i.e. from nested loops to parent loops, thereby missing

On Jun 5, 2012, at 3:20 AM, Martin Apel <martin.apel at SIMPACK.de> wrote: > I am trying to implement loop unrolling in a context, where lots of constant propagation has taken place. > Unrolling an outer loop might make an inner loop have constant bounds, therefore I want to process the loops > outside in, i.e. from parent loops to nested loops. > Unfortunately the standard loop

Hi Martin, > I tried using dragonegg to compile some numerical software of ours. I > tried out two different approaches expecting both would yield the same > results: > 1. gfortran-4.6 -fplugin=dragonegg-3.0 -o test.o test.f (I ommitted a > bunch of additional arguments for brevity) > 2. gfortran-4.6 -fplugin=dragonegg-3.0 -fplugin-arg-dragonegg-emit-ir -S > -o test.ll

Hi all, I tried using dragonegg to compile some numerical software of ours. I tried out two different approaches expecting both would yield the same results: 1. gfortran-4.6 -fplugin=dragonegg-3.0 -o test.o test.f (I ommitted a bunch of additional arguments for brevity) 2. gfortran-4.6 -fplugin=dragonegg-3.0 -fplugin-arg-dragonegg-emit-ir -S -o test.ll test.f llc -O0 -o test.s test.ll as

Hi everyone, I am using the dragonegg plugin to produce bitcode for the following small C program: int main() { 1: int x = -5; 2: x = 6; 3: return 0; } The assignments on lines 1 and 2 are removed even when no optimization flags are specified. I tried making variable "x" volatile, which prevents the assignments from being removed, however I am no longer able to recover the original

OK, with the restrict type qualifier, it is a little bit better: The IR's function signature becomes: define void @foo(i32* noalias %a, i32* noalias %b, i32* noalias %c) nounwind { Now the AA result: Function: foo: 13 pointers, 0 call sites NoAlias: i32* %a, i32* %b NoAlias: i32* %a, i32* %c NoAlias: i32* %b, i32* %c NoAlias: i32* %a, i32** %a_addr NoAlias:

On Fri, Sep 21, 2012 at 3:08 PM, Welson Sun <welson.sun at gmail.com> wrote: > OK, with the restrict type qualifier, it is a little bit better: > > The IR's function signature becomes: > define void @foo(i32* noalias %a, i32* noalias %b, i32* noalias %c) nounwind > { > > Now the AA result: > Function: foo: 13 pointers, 0 call sites > NoAlias: i32* %a,

Here is the result of running mem2reg then basicaa, it is even worse: (%a should be alias to %0, and partial alias to %3) opt -mem2reg -basicaa -aa-eval -print-all-alias-modref-info < foo.s > /dev/null Function: foo: 6 pointers, 0 call sites NoAlias: i32* %a, i32* %b NoAlias: i32* %a, i32* %c NoAlias: i32* %b, i32* %c PartialAlias: i32* %1, i32* %a NoAlias:

Hi, I am studying SSA and some time ago I asked on this list how to see the phi nodes in the llvm ir output. I learned then to use this command: opt -mem2reg test.ll -S > test_mem2reg.ll However, if you look at the output (attached to this message) there is something I do not understand. At the end of the function @f at line 18, the function returns the variable %a_addr.0. However, this

Hi Duncan, >> #include<stdio.h> >> #include<string.h> >> >> int main(int argc, char** argv){ >> >> char a[8] = "aaaaaaa"; >> char b[8] = "bbbbbbb"; >> >> char *c = (char*) malloc(sizeof(char)*(strlen(a)+strlen(b)+1)); >> memcpy(c, a, strlen(a)); >> memcpy(c + strlen(a), b, strlen(b) + 1); >>

Hi Maarten, If you look at the start of basic block 2 (bb2) you'll see the following instruction: %a_addr.0 = phi i32 [ 1, %bb ], [ 0, %bb1 ] ; <i32> [#uses=1] This is an SSA phi node which assigns a value of either 1 or 0 to %a_addr.0 depending on whether control reached the PHI node from basic block bb, or bb1. - Lang. On Thu, Sep 23, 2010 at 11:26 PM, maarten faddegon <

Hello everybody, my problem is, that I want to get an array of pointers to all local variables in a function. This array will be used for transfering these Variables to another execution engine. I've code which generates this array, and a pointer to the target field of the array. name = variables.fname + "_pointerArray"; Instruction* pointerArray = new

Hi Pablo, I can reproduce this with the supplied IR. It is related to the use of __memcpy_chk. As far as I can see it is a bug in lli or the LLVM code generators. Can you please open a bugreport, attaching the LLVM IR. Ciao, Duncan. On 23/01/12 17:00, Pablo Barrio wrote: > Hi Duncan, >>> #include<stdio.h> >>> #include<string.h> >>> >>> int

Hello, I have been facing a few problems getting names of variables from the bitcode. The bitcode does contain debug metadata. The first problem is regarding `memtmp' variables (apparently, the original variable name is no longer present in the bitcode). The other two problems concern OpenMP. In one case, the instruction is not named and hence establishing a connection to the debug metadata

I don't see a way to create a ConstantDataVector from Constant or form APFloat though. Did I oversee that? Is the solution to had a new get function in ConstantDataVector to allow that? Any hint on what would be the right fix otherwise? Thomas -----Original Message----- From: Jonathan Roelofs [mailto:jonathan at codesourcery.com] Sent: Wednesday, January 14, 2015 10:30 AM To: Raoux, Thomas

Can you give an example? And is this limited to C (not C++) only? On Fri, Sep 21, 2012 at 2:52 PM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com> wrote: > I think you may add restrict type qualifier.**** > > ** ** > > Sam**** > > ** ** > > *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] *On > Behalf Of *Welson Sun > *Sent:* Friday,

On Feb 29, 2012, at 2:59 PM, Ashay Rane wrote: > I have been facing a few problems getting names of variables from the bitcode. The bitcode does contain debug metadata. The first problem is regarding `memtmp' variables (apparently, the original variable name is no longer present in the bitcode). The other two problems concern OpenMP. In one case, the instruction is not named and hence