similar to: [LLVMdev] Pass manager question: module pass using function level analysis

> Wojtek, > > Please see David's message below. Have you or can you check in your > code, perhaps as a project for now? That will allow us to start > looking at it and perhaps collaborating on it. Sure. For now, I am posting it as an attachment, because it does not build against the current SVN version. It is really basic (for example, it cannot produce distance vectors,

> I asked myself the same question. Without mod, how do you ensure that for instance the expression 2*i+255 was not actually 2*i-1 ? I think it is not possible in general, but I believe it is possible in case of affine expressions used as GEP indices. I assume, GEP indices (except indexing into struct) are interpreted as signed integers. It isn't explicitly stated in the LangRef, but

Wojtek, Please see David's message below. Have you or can you check in your code, perhaps as a project for now? That will allow us to start looking at it and perhaps collaborating on it. --Vikram Associate Professor, Computer Science University of Illinois at Urbana-Champaign http://llvm.org/~vadve On Aug 20, 2008, at 3:05 PM, David Greene wrote: > On Wednesday 20 August 2008

Hi! Haifeng He wrote: > okay. I guess I figured it out. It seems "poolalloc" needs to be put > in llvm/projects/ directory. Yes, it will compile then. However, it seems the resulting shared library LLVMDataStructure.so (I haven't checked the others) has some undefined symbols. Trying to load it into the opt tool produces an error: undefined symbol:

Hi, Here are my results. Environment: - frontend was built from source, - platform: Linux/x86 (gcc 4.1.2) - Release build - srcdir != objdir Dejagnu summary: # of expected passes 1939 # of expected failures 5 Nightly test report attached. Wojtek -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: report.nightly.txt URL:

Hi, > Cool! I think the most critical part of this is to get a good > interface for dependence analysis. There are lots of interesting > implementations that have various time/space tradeoffs. > > For example, it would be great if Omega was available as an option, > even if the compiler didn't use it by default. This argues for making > dependence analysis

On Aug 20, 2008, at 8:56 AM, David Greene wrote: > What I really need is a dependence analysis interface. I need to know > about loop-carried dependencies and that sort of things, whether two > memory > operations reference the same data, distance information, etc.. As > far as I > can tell, there's no infrastructure for this in LLVM. Right, this is something we've

Hi! I think there is a break missing in switch statement of AddressMightEscape function. It causes redundant recurrent call. Wojtek -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: BasicAliasAnalysis.patch URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070903/481046a5/attachment.ksh>

Hi, I'm working on a simple data dependence analysis pass. I think it would be more natural (in the API and internally) if loops in nests were numbered from 0 than, as it's currently done, from 1. For example, in the former case the loop depth could be directly used to index a direction vector. IMHO it would be more clear in general, not only in the context of my project. Off course,

On Nov 29, 2007, at 11:11 AM, Wojciech Matyjewicz wrote: > As you have noticed, loops aren't represented directly in the LLVM IR. > However, there are analysis passes which may be helpful to > "reconstruct" > them. For example: LoopInfo pass detects natural loops (as sets of > basic > blocks) and ScalarEvolution pass finds loop induction variables (and >

Devang Patel wrote: > Right now, one big missing piece in this puzzle is - dependence > analysis. Right. I was only trying to say that it shouldn't be very difficult to find these for/do loops which are interesting from the parallelization perspective (in general, not all for/do loops can be reconstructed). As for the dependence analysis, I need this piece for my project, and I am

Hi John & Fan, I hit the exact same problem today. I can confirm that Fan's observation of getting the *same* LoopInfo* from subsequent calls to getAnalysis<LoopInfo>(function) for *distinct* functions is indeed true. I was very surprised by this at first as well, but I think I've found an explanation - please anyone correct me if this is wrong: What you're getting from

On Monday 18 August 2008 17:48, David Greene wrote: > > Normally, the conversion to SSA form is sufficient. Can you talk > > about cases where this matters to you? > > Mostly it involves tying into our memory dependence analysis which > annotates things on program points. I need a way to translate back > to our optimizer data structures. > > So it's not

>However, there is one issue I have ignored - possibility of overflow in >the index expression. Suppose, we have such a loop: > for (i8 i = 0; i != 200; ++i) { > A[2 * i + 5] = ... > ... = A[2 * i + 3] > } >If both index expressions are evaluated in 8-bit arithmetic, >then the dependence equation should be solved in modular arithmetic: > 2 * i + 5 == 2 * (i +

Hi! While investigating into the PR1782 I spent some time analyzing BasicAliasAnalysis.cpp. While the mentioned problem should be fixed now (I hope), I have discovered some other possibilities for a bug to occur. In the case of checking for aliasing of two pointer values, where at least one of them is a GEP instruction with out-of-bound indices, BasicAliasAnalysis can return NoAlias, even if the

Hi all, While working on a loadable Alias Analysis module pass, I'm running into the following issue: I'm finding my pass queried for results after it has had 'releaseMemory' called on it and its dependencies, but before runOnModule is called again (on my pass or its deps). As you might expect, this makes my pass rather unhappy (and I think correctly so). This happens with LICM

Hi all! I have recently finished the first prototype of data dependence analysis for LLVM. Now that I have some more time I would like to prepare a "production" version. In this post I'll try to describe the current state and propose a work plan. Currently, the analysis has a very simplified interface (it allows to query for dependence between two given instructions or whether a

Hi, Devang Patel wrote: > LLVM loop transformer operates at loop level, which is not what many > optimizers do in general. So, a loop level interface (i.e. based on > LoopPass in llvm) to find loop-carried dependence is preferable to > loop optimizer. Do you mean making Array Dependence Analysis a loop-level analysis? Would its results be available for some function-level pass

Hi, In the beginning I'd like to say I am not very familiar with (llvm-)gcc internals, so some of my assumptions and guesses may be wrong. Please, correct me, then. Anton Korobeynikov wrote: > Internally OpenMP lowering in gcc is split into two phases. Funny, but > llvm converter is run between these phases :) It looks like second phase > uses some gcc analysis passes (like

>> As part of the advanced compilers course semester project (at >> UIUC), we >> are starting to implement array dependence analysis for LLVM. Great! This is something we've needed for a long time. > I'm currently working on a similar project and hoping to finish it in > about two weeks. Cool! I think the most critical part of this is to get a good