similar to: [LLVMdev] Call in-library only class member

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, On 04/19/2013 09:40 AM, Unnikrishnan C wrote: > access to memory locations. > > example > suppose we have > A[ind1[i]=expr; (s1) > and A1[i]=A[ind2[i]] (s2) > > to find what is the probability for RAW dependence from s1-->s2 and WAR > dependence from s2--->s1 and WAW dependence from s1-->s1 > There exists the

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

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

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

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

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

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

Hi, On 02/24/2013 06:39 PM, Paul Sokolovsky wrote: > 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 -

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, Currently, I have to deal with loop analysis for an ongoing project. As a basis, I use the already existing LoopInfo pass and SCEV as well. However, I'd like to extend the loop analysis and provide some more generic information. For instance, when information regarding loop ranges shall be retrieved, in my opinion LoopInfo and SCEV can only handle static loops (please correct me, if

Hi everyone, I'm happy to announce, that I managed it to make my project "objekt" available at GitHub. You can get the source from https://github.com/sdressler/objekt objekt will be a collection of passes for managing memory objects. It currently consists only of a single pass, which determines the data volume (i.e. the amount of data to be transferred) from a function

Hi, I'm currently working on a pass for symbolic loop analysis and like to start a small discussion. The goal is to get an expression for the loop enabling calculation of e.g. the trip count. Furthermore, inter-loop-dependencies should be regarded. I'm currently testing with Livermore loops. For instance, the following code (Livermore kernel 2) for (l = 1; l <= loop; l++) {

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" =

Hal, On 02/18/2013 06:33 PM, Hal Finkel wrote: [...] >> 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

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

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