similar to: [LLVMdev] printing debug info

The PTX back-end is robust (it's based on the sources used by nvcc), but I'm not sure about the OpenMP representation in LLVM IR. I believe the OpenMP constructs are already lowered into libgomp calls before leaving DragonEgg. It's been awhile since I've loooked at it though. If you use the PTX back-end and have any issues, please don't hesitate to post to the list and cc:

Hi , I doubt LLVM has the infrastructure in place to do so ,One way to accomplish this by implementing decompiler to convert library functions to LLVM IR and run the LLVM analyze pass over converted LLVM IR ,Then revert back from LLVM IR to your library format. Thanks ~Umesh On Thu, Oct 4, 2012 at 9:47 PM, apala guha <aguha at uchicago.edu> wrote: > Hi, > > Is there any

Hi, Is there any way to analyze library functions using LLVM, in the same manner as source code functions? Thanks. -Apala

Hi, Is it possible to translate an OpenMP program to CUDA using LLVM? I read that dragonegg has a OpenMP front-end and LLVM has a PTX back-end. I don't know how mature these tools are. Please let me know. Thanks. -Apala Postdoctoral Scholar Department of Computer Science, University of Chicago Computation Institute, Argonne National Laboratory http://sites.google.com/site/apalaguha/home/

Hi, Is there a way to count branch frequencies using LLVM infrastructure? Thanks. -Apala Postdoctoral Scholar Department of Computer Science, University of Chicago Computation Institute, Argonne National Laboratory http://sites.google.com/site/apalaguha/home/ -------------- next part -------------- An HTML attachment was scrubbed... URL:

Another issue is with ProfileInfo::getExecutionCount(Function* F). Looking at the source code and results, I am seeing that it always returns the execution count of the entry basic block of the function. If the entry basic block is part of a loop, its execution count does not match the function invocation count. Is my assumption wrong, that ProfileInfo::getExecutionCount(Function* F) is

Thanks everyone for the replies. After some experimentation, I found that the order in which the passes are specified matters: opt -O3 -profile-loader matmult.bc -o matmult.opt.bc (works) opt -profile-loader -O3 matmult.bc -o matmult.opt.bc (does not work) Also, I am able to avoid the inconsistency warning only for optimization levels -O3 and -O2. I get that warning when using -O1 and

Hi Apala, Dibyendu is correct that this is likely due to pass order, but things get a bit complicated with -O[1-9] or -std-compile-opts as they insert early passes *before* the profiling code. I recommend that you use identical optimizations to insert instrumentation and to load the profiling data. E.g.: opt -insert-edge-profiling -O3 foo.bc -o foo.2.bc opt -profile-loader -O3 foo.bc

Can we not run the -insert-edge-profiling and -profile-loader passes at the beginning of the opt? Orthogonal point is, is it worth doing any optimizations when -insert-edge-profiling is specified on command line? -Prashantha -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Alastair Murray Sent: Wednesday, September 19, 2012

Hi, I am trying to link archives built by llvm-ar with other bitcode files, using llvm-link. But llvm-link seems unable to read files produced by llvm-ar. Also, clang seems unable to read files produced by llvm-ar. Am I doing something wrong or is this the expected behavior? Is there any work-around? Thanks. -Apala

Thanks Alastair. Is it possible to associate the branch frequency counts with the basic blocks in the intermediate representation? (e.g. Can I access basic block frequencies in runOnFunction()?) Also, I was able to produce a 'llvmprof.out' file. What is the format of this file? How can I parse it? Thanks. -Apala > > > On 09/07/2012 01:25 PM, Alastair Murray wrote: >

On 05/18/2010 01:26 PM, Zheng Wang wrote: > Hello, > > Could I get some debug info at the byte code level? I am writing a > passer and if will be nice if I can know which line in the source an > instruction (or value) corresponds to. > > I found a document online: > http://llvm.org/docs/SourceLevelDebugging.html, but I can't find an > example of doing it at the

I tried getting profile data from LLVM 3.1, using the method mentioned below. I tried it out on a simple matrix multiplication program. However, I noticed the following problems: 1. There is a warning message: "WARNING: profile information is inconsistent with the current program!" 2. The basic block counts (obtained from ProfileInfo::getExecutionCount(const BasicBlock*)) are

On Dec 5, 2012, at 8:15 PM, apala guha <aguha at uchicago.edu> wrote: > I am trying to link archives built by llvm-ar with other bitcode files, using llvm-link. But llvm-link seems unable to read files produced by llvm-ar. Also, clang seems unable to read files produced by llvm-ar. Am I doing something wrong or is this the expected behavior? Is there any work-around? You're not

On 10/9/12 1:19 PM, apala guha wrote: > Hi, > > I am seeing some strange function calls in the LLVM IR, such as, 'call > llvm.lifetime.start'. What are these functions and why are they > appearing in the IR? These are LLVM intrinsics that provide information to the optimization passes. See the Language reference manual (http://llvm.org/docs/LangRef.html) for a

Hi Apala, On 11/09/12 11:20, apala guha wrote: > Is it possible to associate the branch frequency counts with the basic > blocks > in the intermediate representation? (e.g. Can I access basic block > frequencies in runOnFunction()?) Profile data really needs to be loaded at a module level, but once this has been done it can be accessed at any level (including function). In LLVM

Thanks Edwin. I found DebugInfo.cpp may be useful. Could you tell me which function I should call inorder to know the source file name and the line number for a particular instruction? Cheers, Zheng 2010/5/18 Török Edwin <edwintorok at gmail.com>: > On 05/18/2010 01:26 PM, Zheng Wang wrote: >> Hello, >> >> Could I get some debug info at the byte code level? I am

Debuginfo and linker folks, we (AccessSoftek) would like to suggest a proposal for removing obsolete debug info. If you find it useful we will be happy to work on improving it. Thank you for any opinions and suggestions. Alexey.     Currently when the linker does garbage collection a lot of abandoned debug info is left behind (see Appendix A for documentation). Besides inflated debug info size,

Thanks Edwin, I will check it out. Cheers, Zheng 2010/5/18 Török Edwin <edwintorok at gmail.com>: > On 05/18/2010 02:13 PM, Zheng Wang wrote: >> Got it. >> >> I am using LLVM 2.6. I guess  bool getLocationInfo(const Value *V, >> std::string &DisplayName,...) has everything I need.\ > > Yes, for variables. > For instructions see what printStopPoint()

Hi, I am seeing some strange function calls in the LLVM IR, such as, 'call llvm.lifetime.start'. What are these functions and why are they appearing in the IR? Thanks. -Apala