similar to: [LLVMdev] LLVMdev Digest, Vol 50, Issue 33

> > Message: 4 > Date: Tue, 12 Aug 2008 13:23:52 -0700 > From: "Bill Wendling" <isanbard at gmail.com> > Subject: Re: [LLVMdev] A case where llvm created different cfg for > same code > To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Message-ID: > <16e5fdf90808121323g1ae2a2e3lb6c5bd62521df621 at mail.gmail.com> >

Hi, The following two segments of code are actually the same, but llvm created different cfg for them. Form1: 1 #define N 10 2 int test(int A[N][N]) 3 { 4 int i, j; 5 int result =0; 6 for(j=0; j+2<N; ++j) { 7 //for(i=0; i<j && i+j+1<N; i++) { 8 for(i=0; i<j && i<N-j-1; i++) { 9 A[i+j+1][j] = A[j + 2][j-i] + i; 10 } 11 } 12 13 for (i=0; i<N-2; ++i) 14 for (j=0;

> > > Having the final .ll file doesn't help debug this. If you run opt > -analyze -scalar-evolution on the .ll you pasted, it will correctly > print out the loop trip count. > > I've modified llvm-gcc to remove all the passes after indvars. > > I updated my llvm and now it works. >> > Surely the loop trip count is 256, but the Loop::getTripCount()

Hi, i used CVS to checkout the source of llvm and llvm-gcc, compiled and built them on my machine successfully. i tried a c-language hello program, it was OK. But when i tried a c++-language hello program, i got: ~/project/llvm/examples$ llvm-g++ t3.cc -o t3 gccld: /developer/zsth/project/llvm/src/llvm/lib/Analysis/IPA/CallGraph.cpp:277: void

Current llvm-gcc 4.2 building failed on X86-64, here is the dump information: xgcc -B/home/zsth/projects/llvm.org/build/cfe4.2obj/./prev-gcc/ -B/home/zsth/projects/llvm.org/install/x86_64-unknown-linux-gnu/bin/ -I../../../cfe4.2/libcpp -I. -I../../../cfe4.2/libcpp/../include -I../../../cfe4.2/libcpp/include -DENABLE_LLVM -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes

Hi, i want to insert a PHI into one basicblock like this: %s.1 = phi int [ 80, %entry ], [ %tmp21, %bb17 ] then, insert a cast inst. into another basicblock like this: %s.1 = cast int %s.1 to uint But, when i do this, the llvm automatically change the same name into a new one. Actually, i found that sometimes, llvm will create bytecode containing two instructions with same name. So, how can

I found a case which gcc can compile while llvm-gcc can not. I'm using the gcc4.1 and the most recent llvm-gcc. Here is the case: template <int N> class T { public: int V; }; T<4> test(T<4> a[4][8]) { return a[3][3]; } llvm-gcc dumped: fail.cpp: In function \u2018T<4> test(T<4> (*)[8])\u2019: fail.cpp:7: error: invalid use of incomplete type

Hi, Here is C function: uint64_t mul(uint32_t x, uint32_t y) { return x * y; } current llvm-gcc-4.0 with -O3 will compile it to: define i64 @mul(i32 %x, i32 %y) nounwind { entry: %tmp3 = mul i32 %y, %x ; <i32> [#uses=1] %tmp34 = zext i32 %tmp3 to i64 ; <i64> [#uses=1] ret i64 %tmp34 } This seems incorrect. I think it should extend %x, %y to i64 first and

Hi, I encountered a problem about volatile quantifier when using llvm-gcc, here is the example: #define N 10 int sum(volatile int a[N]) { int sum = 0; unsigned i = 0; for (i = 0; i < N; ++i) sum += a[i]; return sum; } If I compile it as C code, then llvm-gcc will dump: define i32 @sum(i32* nocapture %a) nounwind { bb1.thread: %0 = volatile load i32* %a, align 4

Hi, Thanks, John, I just forgot the multi-thread issue. I'll write my own pass to handle this as for my project, it is just single-thread case. Sheng. Date: Thu, 22 May 2008 09:30:45 -0500 > From: John Criswell <criswell at cs.uiuc.edu> > Subject: Re: [LLVMdev] Eliminate Store-Load pair even the LoadInst is > volatile > To: LLVM Developers Mailing List

Hi all, It looks like the induction variable simplification pass prefers doing a zero-extension to compute the wider trip count of loops when extending the IV. This can sometimes result in loss of information making ScalarEvolution's analysis conservative which can lead to missed performance opportunities. For example, consider this loopnest- int i, j; for(i=0; i< 40; i++) for(j=0;

Hi Sheng Am Dienstag, 4. März 2008 schrieb Zhou Sheng: > Current llvm-gcc 4.2 building failed on X86-64, here is the dump I am not followng head closely but may it be that the current head still doesn't support amd64 proper: gcc README.LLVM: "When targeting non-darwin X86-64/AMD-64/EM64-T, configure with --disable-shared. The LLVM X86-64 backend doesn't support PIC codegen on

On Oct 8, 2006, at 1:15 AM, Zhou Sheng wrote: > i want to insert a PHI into one basicblock like this: > > %s.1 = phi int [ 80, %entry ], [ %tmp21, %bb17 ] > > then, insert a cast inst. into another basicblock like this: > > %s.1 = cast int %s.1 to uint > > But, when i do this, the llvm automatically change the same name > into a new one. > In SSA, any assignment

Hi, I'm following http://llvm.org/docs/SourceLevelDebugging.html#debugopt to do the dbgopt testing. But seems, there is something wrong with the Makefile, it told me : llvm-gcc sse.expandfft.c -g --emit-llvm -c -o Output/sse.expandfft.bc llvm-gcc: sse.expandfft.c: No such file or directory llvm-gcc: no input files Am I missing something, like the configure option? -------------- next part

Hello, I am trying to use scalar evolution pass using following command; opt -analyze -mem2reg -indvars -loop-simplify -scalar-evolution < vec.bc when vec.bc is generated using newer version of LLVM i.e LLVM 6 and 7 i get following message in the end; Determining loop execution counts for: @main Loop %8: Unpredictable backedge-taken count. Loop %8: Unpredictable max backedge-taken count. Loop

Here is the code snippet that I am using to create the PHIs in the loop according to the PHIs in the new preheader. At this point I have already redirected the loop backedge and removed the preheader from the loop. for (BasicBlock::iterator II = loopHeaderBB->begin(); (PN=dyn_cast<PHINode>(II)); ++II) { // remove loop back PHI and add it to split BB

> On 2015-Jun-04, at 12:45, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > >> On 2015-Jun-04, at 12:28, Ivan Baev <ibaev at codeaurora.org> wrote: >> >> Hi, we got the following assert: >> >> assert(!Working[0].isLoopHeader() && "entry block is a loop header"); >> >> [in

The Problem? Nowaday, SCEV called "Scalar Evolution" does only evolate instructions that has predictable operand, Constant-Based operand. such as that can evolute as a constant. otherwise we couldn't evolate it as SCEV node, evolated as SCEVUnknown. important thing that we remember is, we do not use SCEV only for Loop Deletion, which that doesn't really needed on nature loops

This looks wrong to me, though the x86 backend produces code that does the right thing (reads each element once). If you change the code (see below) to read each element twice, llvm-gcc still does the right thing but llvm-g++ does not (i.e. it fails to read aech location twice). Current versions of gcc/g++ also look wrong. All 4 compilers (gcc,g++,llvm-gcc,llvm-g++) do the right thing when

Thank You.. I used following command to generate .bc or .ll /Documents/clang+llvm-4.0.0-x86_64-linux-gnu-ubuntu-16.04/bin/clang -O0 -emit-llvm -S -o vec4.ll vecsum.c /Documents/clang+llvm-7.0.0-x86_64-linux-gnu-ubuntu-16.04/bin/clang -O0 -emit-llvm -S -o vec7.ll vecsum.c On Wed, Jan 16, 2019 at 6:49 AM Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > It is hard to tell