similar to: [LLVMdev] DependenceAnalysis and PR14241

On 11/02/2012 11:02 AM, Hal Finkel wrote: > ----- Original Message ----- >> From: "Tobias Grosser" <tobias at grosser.es> >> To: "preston briggs" <preston.briggs at gmail.com> >> Cc: "Benjamin Kramer" <benny.kra at gmail.com>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> >> Sent: Friday, November

Here's the current code (abstracted a bit) const Instruction *Src, const Instruction *Dst, // make sure they are loads and stores, then const Value *SrcPtr = getPointerOperand(Src); // hides a little casting, then Src->getPointerOperand const Value *DstPtr = getPointerOperand(Dst); // ditto // see how underlying objects alias, then const GEPOperator *SrcGEP =

----- Original Message ----- > From: "Tobias Grosser" <tobias at grosser.es> > To: "preston briggs" <preston.briggs at gmail.com> > Cc: "Benjamin Kramer" <benny.kra at gmail.com>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, November 2, 2012 12:56:53 PM > Subject: Re: [LLVMdev]

On 11/02/2012 10:21 AM, Preston Briggs wrote: > > My initial guess is that a conservative fix is quick and small (make > sure the underlying pointers are loop invariant, otherwise give up). A > better approach would be to somehow turn code like the example into > array references that can be analyzed. I'll need to think about this and > do some reading. Hi Preston, I looked

On 02.11.2012, at 15:53, Preston Briggs <preston.briggs at gmail.com> wrote: > Hi Chandler, > > Thanks for writing. > Could you give me some C (or C++) for an illustrative example. > I think I understand your concern, but I'd like to be sure. Hi Preston, The bug report at http://llvm.org/bugs/show_bug.cgi?id=14241 has more details, including a C++ test case. - Ben

Hi Chandler, Thanks for writing. Could you give me some C (or C++) for an illustrative example. I think I understand your concern, but I'd like to be sure. Thanks, Preston -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121102/88c02212/attachment.html>

I see, thanks Ben. So yes, I certainly misunderstood (more likely "misunderstand") how things work. My initial guess is that a conservative fix is quick and small (make sure the underlying pointers are loop invariant, otherwise give up). A better approach would be to somehow turn code like the example into array references that can be analyzed. I'll need to think about this and do

Hi I want to analyse the memory dependencies which exist in a loop at an intra iteration as well as inter iteration (loop carried dependencies). I looked at the DependenceAnalysis implementation which returns a lot of the information I require (based on a prior AliasAnalysis pass), however I need to pass the Src and Dst instructions in program order. I was wondering how I can collect all the

Hi Preston, Thank you for the prompt response. You can use DependenceAnalysis to get the info you want by expensively > testing all pairs of memory references. Isn't all pairs testing incorrect in the sense that a pair may only exist for a certain path? Consider the following example. A[i] = 42; // S1 if( condition ) // C1 { A[i] = 20; // S2 } B[i] = A[i];

add -basicaa to your command line :) On Mon, May 11, 2015 at 7:15 AM, Willy WOLFF <willy.mh.wolff at gmail.com> wrote: > I play a bit more with MemoryDependenceAnalysis by wrapping my pass, and > call explicitely BasicAliasAnalysis. Its still using No Alias Analysis. > > How can I let MemoryDependenceAnalysis use BasicAliasAnalysis? > > Please, find attached my pass. >

Hi, Looking at the output of e.g. llc -mtriple=x86_64-unknown-linux-gnu test/CodeGen/X86/pre-coalesce.ll -debug-pass=Executions Why is it that 'Basic Alias Analysis (stateless AA impl)' is freed much earlier than 'Function Alias Analysis Results' even though the latter depends on the former (at least AFAICT by looking at lib/Analysis/AliasAnalysis.cpp)? Thanks! -Markus

On Wed, Jan 2, 2019 at 1:34 AM Markus Lavin <markus.lavin at ericsson.com> wrote: > To be more specific I am trying to use LVI from inside BasicAA to improve > some cases that turned out to be relevant for our downstream target. > > > > The code is in https://reviews.llvm.org/D55107 and I have problems with a > failing assert in the LazyValueInfoWrapperPass destructor

Hi Mehdi, Thank you for the response. I'm actually on an LTO setup and was referring to PassManagerBuilder::addLTOOptimizationPasses. Here, GlobalsAA is scheduled to run well ahead of SLPVectorizer. However since GlobalsAA is a module pass, it runs once and a bunch of passes, including SLPVectorizer is run for each function. When one of them invalidates the analysis, rest of the functions do

Valmico <valmico88 at gmail.com> wrote: > I'm currently trying to develop new LLVM Pass that will generate > simple data dependencies graph. For now I'm trying to get familiar > with DependenceAnalysis. > My general idea is to traverse each function (runOnFunction) > top to bottom Instruction by Instruction, using DA.depends( I, I2, ...) > on every Instructions

The management of passes in the legacy PM is ... highly confusing. Do you have a specific problem you're trying to solve or a specific question? On Thu, Dec 27, 2018 at 6:47 AM Markus Lavin via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > > Looking at the output of e.g. > > > llc -mtriple=x86_64-unknown-linux-gnu test/CodeGen/X86/pre-coalesce.ll >

Dear LLVM developers, Recently I want to try the pass '-loop-unroll-and-jam' to observe how the IR is transformed, but I don't see the IR changed after doing the following steps. Here are the details for preparing my experiment and I have tried the LLVM 6, 7 and 8: 1) Simple 2D array source code (loop.c) is given ``` #define M 32768 #define N 32768 double a[M][N], b[M][N],

Erkan, you're right. Sorry about that. Attached is the most recent version. Preston Hi Preston, > I am trying to use DA as well. I used your example and commands that you > wrote in order to get DA information. > However, it does not report any dependence info. > I am wondering whether your local copy differs from the one on the > repository ? > Thanks. > Erkan.

Hi, As part of new pass manager work, I've been trying to get something like `opt -foo` working under the NPM, where `foo` is the name of a pass. In the past there's been no reason to keep the names of passes consistent between NPM and legacy PM. But now there is a reason to make them match, so that we don't have to touch every single test that uses `opt`. There are a couple of

Hi, The DependenceAnalysis pass will find loop-carried dependences. However, it is a conservative analysis and will sometimes suggest there may be more dependences than actually exist. In your example, I expect the analysis is confused for some reason and is returning the default confused response. You could test it using the isConfused() method. Note that the DVEntry::ALL direction is always

>You could, in the LTO pipeline, reinsert GlobalsAA after the SLPVectorizer (not saying you should). I didn't realise that adding GlobalsAA* after* SLPVectorizer could help. Thanks for this tip. >There is something fishy. Do you have a test case that reproduce with llvm-lto? I'm currently looking at a proprietary benchmark. I'll try to extract out a simple test case and send it.