similar to: [LLVMdev] llvm get annotations

Hi, I solved it. From the ConstantStruct you can call getOperand() multiple times, so "mine" as deep as you can. On Fri, Mar 1, 2013 at 1:41 PM, Alexandru Ionut Diaconescu < alexandruionutdiaconescu at gmail.com> wrote: > > Hi Sebastian, > > Thanks for the response. > > I already did this : > > I cast the entire annotated expression to Value*. Then, in

Hi Sebastian, Thanks for the response. I already did this : I cast the entire annotated expression to Value*. Then, in order to avoid ugly things like getAsString(), I check if V->getValueID() == Value::ConstantArrayVal in order to cast it to ConstantArray. Because it contains only array[0], I cast array0>getOperand(0) to ConstantStruct. Therefore, from ConstantStruct you can get all the

Hi Dmitry, On 01/09/2013 03:48 PM, Dmitry Mikushin wrote: > Hi Sebastian, > > This kind of analysis is a pretty complex problem in general case. > Consider, for instance, function "f" has nested calls of other functions > with "side effects", meaning they could potentially change the contents of > "in" or "out" indirectly. For this

Are you analysing sizes in order to perform host<->accelerator memory synchronization? 2013/1/9 Sebastian Dreßler <dressler at zib.de> > Hi Dmitry, > > On 01/09/2013 03:48 PM, Dmitry Mikushin wrote: > > Hi Sebastian, > > > > This kind of analysis is a pretty complex problem in general case. > > Consider, for instance, function "f" has nested

----------------- Hello, I want to do a memory dependence profiling. Is there any freely available implementation of memory dependence profiling implementations in LLVM which I can modify for my own use? Unnikrishnan C -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

Hi, suppose the following C function declaration: void f(int *in, int *out); Now further suppose, that _in_ is an array only read from and _out_ is an array that is only written to. Based on this, I was wondering whether there is some already existing LLVM pass (or maybe a part of a pass) that detects those "data directions" for pointers. I'm not quite sure whether e.g. Alias

Hi Sebastian, Sure! The bulk of LMDA was written by Aparna Kotha (CCd). It computes dependences between all instructions, computes the resulting direction vectors in the function, then associates them all with loops. At a high level, the dependence analysis consults with AliasAnalysis, and ScalarEvolution before resorting to attempting to understand the effective affine expressions and

Hello, On Sun, 24 Feb 2013 19:15:27 +0100 Sebastian Dreßler <dressler at zib.de> wrote: [] > For a project involving a tree data structure, we created a graph for > representing IR for further analysis. I attached an excerpt of such a > graph to give you an idea. If it helps, we will see how to proceed ;) Well, after grepping LLVM source for apparent lack of it and googling for

Hi Sebastian, This kind of analysis is a pretty complex problem in general case. Consider, for instance, function "f" has nested calls of other functions with "side effects", meaning they could potentially change the contents of "in" or "out" indirectly. For this reason, even current state-of-art commercial APIs that imply strong data analysis (like OpenACC

First, let me ask if there's a page that documents the testing process in full. If there is, just give me a link to that and save yourself the time of answering this. (I did Google it, all I found was docs on writing tests for LLVM.) Sorry if this is way off, but I have no idea what to download and unpack to start testing. I know it's stuff from here:

Hi Tyler, On 05/09/2013 07:03 AM, Tyler Hardin wrote: > First, let me ask if there's a page that documents the testing process in > full. If there is, just give me a link to that and save yourself the time > of answering this. (I did Google it, all I found was docs on writing tests > for LLVM.) > > Sorry if this is way off, but I have no idea what to download and unpack to

Hi Paul, On 02/24/2013 08:54 PM, Paul Sokolovsky wrote: > Hello, > > On Sun, 24 Feb 2013 19:15:27 +0100 > Sebastian Dreßler <dressler at zib.de> wrote: > > [] > >> For a project involving a tree data structure, we created a graph for >> representing IR for further analysis. I attached an excerpt of such a >> graph to give you an idea. If it helps,

Hi, On 03/03/2013 07:09 AM, Timothy Mattausch Creech wrote: > [...] > The main components of the released implementation are loop memory > dependence analysis and parallel code generation using calls to POSIX > threads. The loop memory dependence analysis sounds very interesting to me. Could you provide some more information regarding its capabilities? Cheers, Sebastian -- Mit

----- Original Message ----- > From: "Timothy Mattausch Creech" <tcreech at umd.edu> > To: "Sebastian Dreßler" <dressler at zib.de> > Cc: "Aparna Kotha" <akotha at umd.edu>, llvmdev at cs.uiuc.edu > Sent: Sunday, March 3, 2013 11:32:49 AM > Subject: Re: [LLVMdev] AESOP autoparallelizing compiler > > Hi Sebastian, > Sure!

Hello, LLVM provides several ways to visual IR structure straight in its core - Function::viewCFG() to render control flow graph, then -view-* options to llc to render various stages of transforming to machine code. However, I wasn't able to find a way to render complete DAG visualization of normal IR - which besides CFG would also show dataflow (and other flows, if any). What people use to

Hi, We would like to inform the community that we're releasing a version of our research compiler, "AESOP", developed at UMD using LLVM. AESOP is a distance-vector-based autoparallelizing compiler for shared-memory machines. The source code and some further information is available at http://aesop.ece.umd.edu The main components of the released implementation are loop memory

Hi, In the past months we were working on two LLVM passes which use data objects of functions as input. One pass computes the "data-direction" (FORTRAN users know this as intent) of the object, i.e. whether it is read-only, write-only or read-write. The second pass injects code into the LLVM module that, when called at run-time, computes the memory footprint of the object. This also

I can get the loop header block by using getAnalysis < LoopInfo > ( *F ).isLoopHeader( BB ) But is there any way with with you can also check the blocks containing backedge. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130220/198e4421/attachment.html>

----- Original Message ----- > From: "Sebastian Dreßler" <dressler at zib.de> > To: llvmdev at cs.uiuc.edu > Sent: Monday, February 18, 2013 7:49:39 AM > Subject: [LLVMdev] Passes for object memory footprint / data-direction > > Hi, > > In the past months we were working on two LLVM passes which use data > objects of functions as input. One pass

Hi, for a current project I'm required to get the types of the template arguments key and value for std::map<K,V>. I've noticed that the STL implementation used by Clang defines the type of the map as %"class.std::map" = type { %"class.std::_Rb_tree" } which then is further defined and finally ends as %"struct.std::_Rb_tree_node_base" =