similar to: [LLVMdev] Get the loop trip count variable

On Mon, Apr 5, 2010 at 1:19 PM, Zheng Wang <jason.wangz at gmail.com> wrote: > Hello, > > I am wondering whether I can get the variable name of loop trip count in LLVM? > > For example, > > int NUM; > > NUM=atoi(argv[i]); > > for (int i=0; i<NUM; i++) > { >    ... > } > > How can I get the corresponding variable name for "NUM"?

Hi, On 04/05/2010 10:51 PM, Eli Friedman wrote: > On Mon, Apr 5, 2010 at 1:19 PM, Zheng Wang<jason.wangz at gmail.com> wrote: >> Hello, >> >> I am wondering whether I can get the variable name of loop trip count in LLVM? >> >> For example, >> >> int NUM; >> >> NUM=atoi(argv[i]); >> >> for (int i=0; i<NUM; i++) >>

Hi Eli, Could you tell me how to extract the variable name? The reason I want to do it at the IR level is because I have more information at this stage, such as, constant propagation and back edges. Cheers, Zheng On 5 April 2010 21:51, Eli Friedman <eli.friedman at gmail.com> wrote: > On Mon, Apr 5, 2010 at 1:19 PM, Zheng Wang <jason.wangz at gmail.com> wrote: >> Hello,

Thanks a lot for your guys' help!!! I guess once I am able to get *V* (which probably is a pointer to a Value object), then, I can instrument some code at the IR level to dump V. As long as I maintain V at this pass stage, I should be able to dump the loop trip count. This is true, isn't it? Basically, what I am going to do is to add a function call before the loop body, such as:

Hello Andreas, Thanks! But I could not find -insert-optimal-edge-instrumenation pass from "opt -help". Did you mean -insert-edge-profiling? Cheers, Zheng On 7 April 2010 12:29, Andreas Neustifter <astifter-llvm at gmx.at> wrote: > Hi, > > On 04/05/2010 10:51 PM, Eli Friedman wrote: >> >> On Mon, Apr 5, 2010 at 1:19 PM, Zheng Wang<jason.wangz at

Sorry, I could not the the loop trip count with getTripCount(). I used a simple program as a test case: ------------------------------------------------------ #include <stdio.h> int getV(int i) { return i * 2; } int main() { int num = 10; int sum=0; int i; for (i=0; i<num; i++) { sum += getV(i); } return 0;

Hello, I have a problem of generating a load instruction. The LLVM bytecode is: ------------------------ entry: ... %2 = call i32 (...)* @atoi(i8*%1) nounwind /*<- Insertpos*/ ... -- bb1: .. %5 = icmp sgt i32 %2, %i.0 ... ----------------- Now I have pb: pointer to the Value object of *%2* of bb1. Here, I want to generate a load instruction and I did it as: new LoadInst(pb,

Zheng Wang <jason.wangz at gmail.com> writes: > I have a problem of generating a load instruction. The LLVM bytecode is: > > ------------------------ > entry: > ... > %2 = call i32 (...)* @atoi(i8*%1) nounwind > /*<- Insertpos*/ > ... > > -- > bb1: > .. > %5 = icmp sgt i32 %2, %i.0 > ... > ----------------- > > > Now I have >

Hello, How to check whether a value object is within a particular basic block or not. I have the following LLVM bytecode: ------------------------ entry: ... %2 = call i32 (...)* @atoi(i8*%1) nounwind ... -- bb1: .. %5 = icmp sgt i32 %2, %i.0 ... ----------------- Here I got the corresponding pointer of the Value object of *%2*. How can I check whether it is defined in *entry* or

Zheng Wang wrote: > Hello, > > How to check whether a value object is within a particular basic block or not. > There is a much simpler way to do this. Assuming that Value * pb holds the pointer to the value of %2, you do the following: 1) Check to see if %2 is an instruction (use dyn_cast<Instruction>(pb) and see if the result is NULL). If it's not an instruction,

Hello, I'm finding problems with BackEdgeTaken count calculation in even simple fortran loops with gfortran-4.6 + DragonEgg 3.0. Even for simple double loops like this one: program test2 integer i,j,k dimension k(100,100) do j=1,100 do i=1,100 k(i,j) = i enddo enddo write(*,*) k(1,30) end make the ScalarEvolution

Attached 2012/2/8 Marcello Maggioni <hayarms at gmail.com>: > Mmm, sorry, the patch I posted crashes if ExitBr is null (which it may > be ...) , this one should be ok (and passess all the ScalarEvolution > tests in LLVM): > > diff --git a/lib/Analysis/ScalarEvolution.cpp b/lib/Analysis/ScalarEvolution.cpp > index daf7742..b10fab2 100644 > ---

Well, it wasn't intended as a "real" patch to be included , but more as a "proof of concept" for a solution. Do you think it is a valid solution and I'm correct in my assumption? If so then I'll clean up the patch and attach a testcase for inclusion. Thanks! Marcello 2012/2/9 Nick Lewycky <nlewycky at google.com>: > Your patch should include a testcase,

This is the .ll for that graph (attached). I think I understand what you are saying. This particular testcase returns CNC not because the exit block doesn't have a unique predecessor, but because the unique predecessor (the inner loop block) has a successor that is inside the loop (in this case itself, because it's the inner loop block). That doesn't change, anyway, the assuption that

Mmm, sorry, the patch I posted crashes if ExitBr is null (which it may be ...) , this one should be ok (and passess all the ScalarEvolution tests in LLVM): diff --git a/lib/Analysis/ScalarEvolution.cpp b/lib/Analysis/ScalarEvolution.cpp index daf7742..b10fab2 100644 --- a/lib/Analysis/ScalarEvolution.cpp +++ b/lib/Analysis/ScalarEvolution.cpp @@ -4293,9 +4293,15 @@

Your patch should include a testcase, see test/Analysis/ScalarEvolution for examples. "BranchInst* " should be "BranchInst *". You should have spaces after the // in your comments. One of the comment lines isn't indented properly. Nick On 8 February 2012 12:05, Marcello Maggioni <hayarms at gmail.com> wrote: > Attached > > 2012/2/8 Marcello Maggioni

Can I do this in my own pass module? Because the string is actually depended on the type of a value object. On 8 April 2010 20:29, Eli Friedman <eli.friedman at gmail.com> wrote: > On Thu, Apr 8, 2010 at 12:18 PM, Zheng Wang <jason.wangz at gmail.com> wrote: >> Hiya, >> >> I want to declare a constant global variable as: >> >> @.str = private constant

On 8 February 2012 15:50, Marcello Maggioni <hayarms at gmail.com> wrote: > Well, it wasn't intended as a "real" patch to be included , but more > as a "proof of concept" for a solution. Do you think it is a valid > solution and I'm correct in my assumption? If so then I'll clean up > the patch and attach a testcase for inclusion. > I'm

This is instead a very simple (handmade) test case that triggers the problem (attached) Also a more conforming patch has been attached 2012/2/9 Marcello Maggioni <hayarms at gmail.com>: > This is the .ll for that graph (attached). I think I understand what > you are saying. > This particular testcase returns CNC not because the exit block > doesn't have a unique predecessor,

FInally I had the time to complete everything up. Now I included the test case in the patch and the testcase runs with the LLVM tests system. 2012/2/9 Marcello Maggioni <hayarms at gmail.com>: > This is instead a very simple (handmade) test case that triggers the > problem (attached) > Also a more conforming patch has been attached > > 2012/2/9 Marcello Maggioni <hayarms