similar to: [LLVMdev] llvm print-memdeps segfault

Howdy, I'm working on writing a dependence analyzer (rather like what LoopDependenceAnalysis wants to be, except a bit more general). While this is a problem of many parts, I'm currently focusing on finding pairs of memory references to test for dependence. Consider this contrived C code: double test2(int n, double *restrict A, double *restrict B, bool flag) { if (flag) { A[0] =

Hello everyone, Till now I have succesfully running passes using RegisterPass template. I have encountered a segfault in my pass. Assertion `AA && "AA didn't call InitializeAliasAnalysis in its run method!"' failed. Then, I tried to use INITIALIZE_PASS_XXXX or INITIALIZE_AG_PASS template, together with `*llvm::createMyMemDepPrinter()` and

Hi All, Looking at the code of MemDepPrinter.cpp, I saw the char MemDepPrinter::ID = 0; > INITIALIZE_PASS_BEGIN(MemDepPrinter, "print-memdeps", > "Print MemDeps of function", false, true) > INITIALIZE_PASS_DEPENDENCY(MemoryDependenceAnalysis) > INITIALIZE_PASS_END(MemDepPrinter, "print-memdeps", > "Print MemDeps of function", false, true)

Hi there, I was trying to see what kind of informations I can get on dependence/alias analysis from the trunk llvm, and stumbled upon two potencial problems. First of all, the most recent documentation I could find online <http://llvm.org/docs/AliasAnalysis.html> suggests the use of options not available on the code (like enabling globalsmodref-aa, or count-aa, for example). Is there a more

Hello! I am trying to retrieve all instructions from a function's body that are dependent on a specific argument. The strategy I am currently using for that is to follow all uses of the argument and record them. Also, whenever I encounter a store of a dependent value, I try to find loads in the function that are dependent on that store and resume use-tracking from there. For this purpose I am

On Mon, Jan 16, 2017 at 2:46 AM, Mikael Holmén <mikael.holmen at ericsson.com> wrote: > Hi, > > On 01/13/2017 10:29 PM, Daniel Berlin wrote: > >> Yeah, there's a lot of things this could be. >> >> On the memdep side: >> Note that memdep is not actually properly updated in all cases by most >> passes that claim to not invalidate it (they

On Mon, May 4, 2015 at 2:19 PM, Nicholas White <n.j.white at gmail.com> wrote: >> It's not quite the same testcase. > Yes - it's an extension of the first test case that I'd expect to be > optimised out in the same way as my earlier example (i.e., store a > value, read it back and branch on it). If you miss out the > "check.first.array.element" block

Hello to whom this may concern, Versioned this as I saw identical title before. I'm compiling a clang project where I'm seeing GVN mess up and replace a load with a wrong def value. I am using LLVM-3.5, but the problem has been observed upto 3.8. To illustrate the problem, define i32 @main scalar.ph: <initialize [80 x i16] %dest> ... preheader: %index=0 br test, loop1, bb2

Thanks for quick reply Daniel, I tried to make a simple C testcase, but could not reproduce the same condition with output from Clang. I suppose I could modify the C code to make it look similar with TBAA's; I may be able to provide this by eod. > store %ptr above the load. My mistake; I was referring to the store $lcssa in bb2. Looking at the C source code, it should definitely alias

before inlining all 20005 after inlining somewhere here changed made it NoAlias after Global Variable Optimizer 20014 20373 20255 20372 20254 before GVN 19993 20011 19991 20010 20030 It appears that TBAA metadata certainly changed after inlining and subsequent passes. I have attached the .bc file. I think I will try to dump out more TBAA metadata between passes. The method in

Introduction ============ I'm currently in the middle of what initially looked to be a simple change in GVN but is turning out to have unexpected consequences that are turning out to be quite difficult to resolve, so I thought I'd send out an RFC to make sure that I'm not barking up the wrong tree with how I'm trying to do this. Motivation and current behaviour

Hi there, I am doing: opt -print-memdeps ./test.bc -analyze -globalsmodref-aa by adding globalsmodref-aa, I am hoping that globalsmodref alias analysis will be used. However, it does not turn out to be so. I found this out by adding some "errs() << " into the source code for that alias analysis. So my question is what should I do to let memory dependency analysis use

Philip Reames wrote: > T.M.K., there's no direct way to test it. There is. See the 'unittests/' directory which contains the C++ unit tests. See unittests/IR/UserTest.cpp for an example that builds up IR from a .ll-in-a-C-string then queries C++ API operations on it. Nick You have to construct a > transformation which happens with the information you added and not >

2015-12-26 18:32 GMT+01:00 Philip Reames <listmail at philipreames.com>: > On 12/26/2015 02:17 AM, Amaury SECHET via llvm-dev wrote: > > I'm trying to fix that bug: https://llvm.org/bugs/show_bug.cgi?id=20049 > > It turns out this is the kind of optimization that I really need, as when > it isn't done, all kind of other optimizations opportunities down the road

I'm trying to fix that bug: https://llvm.org/bugs/show_bug.cgi?id=20049 It turns out this is the kind of optimization that I really need, as when it isn't done, all kind of other optimizations opportunities down the road are not realized as they are not exposed. I have no idea where to start digging for this. I assume there is some kind of interaction between memory dependency and alias

On Mon, May 4, 2015 at 9:40 AM, Nicholas White <n.j.white at gmail.com> wrote: > Thanks - that makes sense. It's interesting that at -O3 the optimizer > can't reduce the below though - I'll dig into it a bit and see if I > can make a patch that fixes it: I'm unsure what you expect to happen below. It's not quite the same testcase. GVN will PRE the loads, so you

On 1/21/13 5:22 AM, Alexandru Ionut Diaconescu wrote: > Hello everyone ! > > I am trying to determine for certain Load instructions from my pass > their corresponding Alloca instructions (that can be in other previous > blocks). The chain can be something like : `TargetLoad(var) -> other > stores/loads that use var (or dependencies on var) -> alloca(var).` , > linked

Hello everyone ! I am trying to determine for certain Load instructions from my pass their corresponding Alloca instructions (that can be in other previous blocks). The chain can be something like : `TargetLoad(var) -> other stores/loads that use var (or dependencies on var) -> alloca(var).` , linked on several basic blocks. Do you know how can I do it? I tried to use the methods from

Based on function names and structures, this is some version of GCC :) Any way you can post the entire .ll file? Because it's globalsmodref, it's hard to debug without the other functions, since it goes over all the functions to determine address takenness, etc :) On Tue, Jul 21, 2015 at 3:23 PM, Michael Zolotukhin <mzolotukhin at apple.com> wrote: > Hi Chandler, > > We

Hi, MemDep caches results for local queries and provides means to invalidate them by keeping reverse maps. Unfortunately, it also caches results that represent non-local dependencies, for which there are no reverse map entries, and thus those entries can not be invalidated. This is a problem when an optimization turns a non-local dependency into a local one.