similar to: [LLVMdev] llvm-ar

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, 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 any way to analyze library functions using LLVM, in the same manner as source code functions? Thanks. -Apala

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

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

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:

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

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

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: >

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

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

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

Hi Tim, This is C++ indeed. Basically, I am profiling the code. So, these edges that cannot be resolved at compile time present a problem. Where can I find these devirtualization optimizations that you mentioned? Thanks. -Apala On 01/01/2013 12:18 PM, Tim Northover wrote: > > Hi, > > > For example: call void %1608(%"struct.LRT::RGBAucharFrameBuffer"* > > %1604)

> On Jan 17, 2017, at 12:33 PM, Stephen Checkoway <s at pahtak.org> wrote: > > >> On Jan 17, 2017, at 10:11, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Actually you have to opt-in instead of opt-out right now, and I encourage you to try it if you’re contributing to LLVM:

On Wed, Nov 20, 2013 at 8:55 PM, Stephen Checkoway <s at pahtak.org> wrote: > > This has come up before <https://groups.google.com/forum/#!topic/llvm-dev/vomnIQjefzA>. I don't recall if there was a resolution. > Thanks for the link, completely missed when googled the issue. I think no consensus was reached (I cannot find any commit in the repository addressing such

On Oct 28, 2013, at 2:02 PM, Tyler Hardin <tghardin1 at catamount.wcu.edu> wrote: > See the source here: https://github.com/earl/llvm-mirror/blob/master/lib/Target/X86/InstPrinter/X86IntelInstPrinter.cpp. It looks like getRegisterName might do what you want, but I don't know where it's coming from. (Whether it's a function or a member of a super class. Hopefully, if it's

On Nov 15, 2013, at 11:16 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > Taking a really quick at the gold code it looks like it tries to keep > 8176 files open. I would suggest putting a breakpoint in > Descriptors::close_some_descriptor and checking why it is failing to > close the files. That is a lot of file descriptors to keep open. It's well above my

I'm iterating over MCInsts and I'd like to examine particular instructions. For example, I'd like to look at all x86 CALL64m instructions. I may be missing something, but it seems like my only option is to use MCInstPrinter::getOpcodeName and compare strings. (Of course, I could iterate through the opcodes and build up a table of the ones I'm interested in to avoid string