similar to: [LLVMdev] Loop dependence analysis

Hi Sanjoy, I reworked the code for analyzeStrongSIV to fix a couple of mistakes, plus squeeze all the advantage possible from the symbolic manipulation provided by the SCEVs. It's sketched out here: https://sites.google.com/site/parallelizationforllvm/strong-siv-test Does it makes sense to you? Thanks, Preston On Thu, Apr 5, 2012 at 4:09 PM, Preston Briggs <preston.briggs at

Hi Sanjoy, Reading through LoopDependenceAnalysis::analyseStrongSIV(), I noticed one problem and one confusion. My confusion related to your naming of the two instructions as A and B. It's consistent all through LoopDependenceAnalysis. I'd prefer something like source and destination, so I can keep track of which is which. It didn't matter so much when you were simply proving or

Hi, When I write various test cases and explore how they're handled by the code in LoopDependenceAnalysis::analysePair, I'm surprised. This loop collects pairs of subscripts from the source and destination refs. * // Collect GEP operand pairs (FIXME: use GetGEPOperands from BasicAA), adding* * // trailing zeroes to the smaller GEP, if needed.* * GEPOpdsTy destOpds, srcOpds;* *

Hi Hideki, I like this summary overall, thanks. More below. > On May 20, 2016, at 10:04 AM, Saito, Hideki <hideki.saito at intel.com> wrote: > > > To the best of my experience, handling case B (secondary induction) is must-have, and if I’m not mistaken, > people aren’t opposed to that. > > For me, handling case A (primary induction) is “why not?”, but I certainly

My response to this patch is below, but adding a floating-point feature to SCEV should really be hashed out on the llvm-dev list first. I would like to get the attention of floating-point experts on the design review. I’d like to see a small design proposal justifying the feature and defending it’s soundness. My concern is that the approach may not be sound, but providing this core API would

On Wed, 18 Apr 2012 18:16:47 -0700 Preston Briggs <preston.briggs at gmail.com> wrote: > Hi Sanjoy, > > Here's a version of Banerjee and Wolfe's Exact SIV test: > https://sites.google.com/site/parallelizationforllvm/weak-siv-test > It assumes you've already filtered out the easy cases handled by ZIV, > strong SIV, etc. > > I'm not confident about my

Adding support for FP inductions through isInductionPHI() is certainly possible, I have a relatively small local patch that does exactly that for simple fp add-recurrence cases, along with changes to the vectorizer to make it aware of FP inductions. It won't get give you the powerful reasoning capabilities of SCEV, but for the B-like cases it should work. Amara On 20 May 2016 at 19:31, Adam

On Wed, May 16, 2018 at 1:24 AM, Nema, Ashutosh <Ashutosh.Nema at amd.com> wrote: > Hi Sanjoy, > > Your inputs really helped. > > Using “isImpliedCond”, able to relate and find the min for cases like: > > SCEV1: (-1 + (sext i32 %n.addr.058 to i64))<nsw> > SCEV2: 0 > Extra-Condition: (n.addr.058 > 7) > Result: ‘0’ (SCEV2) > > I have another case

Hi Sanjoy, Your inputs really helped. Using “isImpliedCond”, able to relate and find the min for cases like: SCEV1: (-1 + (sext i32 %n.addr.058 to i64))<nsw> SCEV2: 0 Extra-Condition: (n.addr.058 > 7) Result: ‘0’ (SCEV2) I have another case where trying to find min between two SCEVs under an extra condition. “isImpliedCond” is not helping for below case, may be I’m missing something:

@Sanjoy, what's the issue with <nsw>? Moreover, why can't SCEV detect that x is loop invariant and just take the diff/incr? On Fri, Sep 16, 2016 at 2:50 PM, Kevin Choi <code.kchoi at gmail.com> wrote: > Assuming compiler assumes program is free of UB, I suppose trip count of 2 > is always valid. I misplaced valid to trip count when it should've been >

Hi Hal, Preston! Sorry for the delay! Got busy with some offline work. I've worked on my previous code to calculate direction and distance vectors whenever possible (strong SIV, basically). I think the current code is much clearer and would like your opinions on it. I have attached the patch and also pushed to the github repo I mentioned [1]. Thanks! [1]

Hi Pankaj, On Tue, Mar 13, 2018 at 1:55 PM, Chawla, Pankaj <pankaj.chawla at intel.com> wrote: > Thanks for the reply! > Would it be possible for you to implement this? I don't have cycles for this right now, but if you file a bug I can give this a shot when I have time later. Even in the best case this will have to at least wait until end of April because I'm leaving for a

Hi Sanjoy, Thanks for the reply! Would it be possible for you to implement this? You know the codebase better than I do. Thanks, Pankaj -----Original Message----- From: Sanjoy Das [mailto:sanjoy at playingwithpointers.com] Sent: Tuesday, March 13, 2018 1:34 PM To: Chawla, Pankaj <pankaj.chawla at intel.com> Cc: Maxim Kazantsev <max.kazantsev at azul.com>; Serguei Katkov

For reference, the case with a variable loop count is filed as PR27894: https://llvm.org/bugs/show_bug.cgi?id=27894 And the case with a constant loop count is filed as PR27899: https://llvm.org/bugs/show_bug.cgi?id=27899 On Thu, Jun 2, 2016 at 7:48 AM, Demikhovsky, Elena via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I implemented IV simplification with FP SCEV and uploaded a new

>What situations are they common in? ICC Vectorizer made a paradigm shift a while ago. If there aren’t a clear reason why something can’t be vectorized, we should try our best to vectorize. The rest is a performance modeling (and priority to implement) question, not a capability question. We believe this is a good paradigm to follow in a vectorizer development. It was a big departure from

I've been doing some digging in this area (scev, wrapping arithmetic), learning as much as I can, and have reached a point where I'm fairly confused about the semantics of nuw in scalar evolution expressions. Consider the following program: define void @foo(i32 %begin) { entry: br label %loop loop: %idx = phi i32 [ %begin, %entry ], [ %idx.dec, %loop ] %idx.dec = sub nuw i32

> On Sep 16, 2016, at 2:23 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Hi Mehdi, > > Mehdi Amini wrote: > > > >> On Sep 16, 2016, at 1:56 PM, Kevin Choi via llvm-dev > >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > >> > >> > int mat[9][9][9]; > >> > for (p =

To the best of my experience, handling case B (secondary induction) is must-have, and if I’m not mistaken, people aren’t opposed to that. For me, handling case A (primary induction) is “why not?”, but I certainly admit that that can be very naïve thinking coming from lack of good understanding on SCEV and their proper usages. Now, let’s assume we can postpone discussion about case A. What is the

> One option would be to extend InductionDescriptor::isInductionPHI in the vectorizer to directly analyze the PHIs without SCEV support as Sanjoy suggested. I *think* that that could be sufficient to handle case B. I implemented this with FP SCEV and the code looks very structured, including SCEVExpander. Extending the existing structures without implementing FP SCEV will be problematic. And

Hi Wei, Wei Mi wrote: > Sanjoy and Andy, thanks a lot for your suggestions. > > On Wed, Aug 24, 2016 at 8:53 AM, Andrew Trick<atrick at apple.com> wrote: >> >>> On Aug 23, 2016, at 11:30 PM, Sanjoy Das<sanjoy at playingwithpointers.com> wrote: >>> >>> Hi Wei, >>> >>> I've not seen GCC's SCEV so I cannot