similar to: [LLVMdev] Using DependenceAnalysis::depends

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

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

2013/8/8 Preston Briggs <preston.briggs at gmail.com> > > Hi, > > The DependenceAnalysis pass isn't reliable yet; it has several errors that > need to be corrected. These manifest by the analysis claiming there's no > dependence when one in fact exists. > > Your proposed scheme of testing every pair of instructions is > asymptotically expensive, requiring

Hi Snehasish, thanks for writing up the proposal. As it stands today, path profiling still has serious scalability issue that prevents it from being usable by any optimization passes that may benefit from it. On the other hand, sampling based approach can still be promising. For instance, LBR can potentially together with static CFG constructed from the binary can be used to form path(let)

Hi David, > Hi Snehasish, thanks for writing up the proposal. > > As it stands today, path profiling still has serious scalability issue that > prevents it from being usable by any optimization passes that may benefit > from it. I agree; it would be an interesting to see how we can reduce the overheads to bring it within acceptable limits. > It will be interesting to see how

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

Hi David, > Are the data below all collected when only one function is picked for > instrumentation? Yes, here is a list of the benchmarks and selected functions. +-----------------+----------------------------------------------------------------------------------------------+ | blks | _Z19BlkSchlsEqEuroNoDivfffffif |

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

Hi I am pinging to find out if there is any interest to mentor this proposal for GSoC this year? I've submitted a draft via the GSoC website. David, Vedant it would be great if I could get some advice on refining the goals and particulars of the implementation. The version we use internally is not performance oriented and will require refactoring. Here is a link to the draft document [1].

Hey Preston, I wanted to let you know that we found a really serious problem with DependenceAnalysis in PR14241. In summary, DA seems to have a baked-in assumption that the base pointer of the GEPs it inspects are loop invariant. It appears to only do analysis on the subscripts. This is especially important for LLVM because C++ code (compiled through Clang) very frequently expresses loops as

Hi all, Sorry for having been quiet for so long, I have my university exams going on, and will be able to contribute only after the coming Friday. Thanks! -- Sanjoy Das http://playingwithpointers.com

On Sat, Apr 21, 2012 at 6:08 AM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Sorry for having been quiet for so long, I have my university exams > going on, and will be able to contribute only after the coming Friday. Gents, While you've been fooling around with exams, I have been focused with laser-like intensity, or something... Here are new versions of 4 SIV

Gents, I spent some time reading over Sanjoy's patch for LoopDependenceAnalysis. Unfortunately, an early version of these notes escaped; this is the complete review. First off, I agree with his choice to implement the SIV tests. For scientific Fortran, the SIV (and the simpler ZIV) tests cover about 85% of the cases in practice. For C and C++, I expect the percentage will be much higher.

Hi, I want to create a copy of DependenceAnalysis downstream. At first I tried the HelloWorld tutorial. But then I figured, maybe I should move on to create my pass by mimicking some other pass in LLVM. So, I tried copying DependenceAnalysis itself [1] Although after a lot of time of trying it compiled, I'm pretty sure I have done it completely in the wrong way. What is more, I can't

Hello, 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 combination in function to check if they are dependent on any

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>

Hi, Here is a preliminary (monolithic) version you can comment on. This is still buggy, however, and I'll be testing for and fixing bugs over the next few days. I've used your version of the strong siv test. Thanks! -- Sanjoy Das. http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.diff Type: application/octet-stream