similar to: [SCEV] Inconsistent SCEV formation for zext

Hi, +CC Max, Serguei This looks like a textbook case of why caching is hard. We first call getZeroExtendExpr on %dec, and this call does end up returning an add rec. However, in the process of simplifying the zext, it also calls into isLoopBackedgeGuardedByCond which in turn calls getZeroExtendExpr(%dec) again. However, this second (recursive) time, we don't simplify the zext and cache a

Hi Sanjoy, Thanks for investigating the issue! I am more interested in getting the underlying problem fixed rather than making this particular test case work. I think I have more test cases where this problem crops up. I would any day prefer consistent results over compile time savings which can lead to inconsistencies. These inconsistencies require significant developer time to analyze and fix

This sounds fine to me (and sorry for the delay!). -- Sanjoy On Mon, Mar 12, 2018 at 1:09 PM, Chawla, Pankaj <pankaj.chawla at intel.com> wrote: > Hi Sanjoy, > > So what is the verdict on this issue? > > Thanks, > Pankaj > > > -----Original Message----- > From: Chawla, Pankaj > Sent: Monday, February 26, 2018 11:12 AM > To: Sanjoy Das <sanjoy at

Hi Sanjoy, >> I'm a bit apprehensive of adding more caching to solve problems created by caching; but if there is no way out of adding another cache, how about adding a cache that maps SCEV expressions to their simplified versions? Then we could do something like: I may be wrong but I think caching is not an issue in itself, but caching in the presence of self-recursion is. >>

Hi Pankaj, On Sun, Feb 11, 2018 at 2:32 PM, Chawla, Pankaj <pankaj.chawla at intel.com> wrote: > Thanks for investigating the issue! > > I am more interested in getting the underlying problem fixed rather than making this particular test case work. I think I have more test cases where this problem crops up. I would any day prefer consistent results over compile time savings which

Hi Sanjoy, So what is the verdict on this issue? Thanks, Pankaj -----Original Message----- From: Chawla, Pankaj Sent: Monday, February 26, 2018 11:12 AM To: Sanjoy Das <sanjoy at playingwithpointers.com> Cc: Maxim Kazantsev <max.kazantsev at azul.com>; Serguei Katkov <serguei.katkov at azul.com>; llvm-dev at lists.llvm.org Subject: RE: [SCEV] Inconsistent SCEV formation for

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

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

On Tue, Dec 18, 2012 at 9:56 AM, Matthew Curtis <mcurtis at codeaurora.org> wrote: > > Here's how I'm evaluating the expression (in my head): > > 00: Add(ZeroExtend(Truncate(Minus(AddRec(Start=0,Step=3)[n],3), i8), i32),3) > | > 01: Add(ZeroExtend(Truncate(Minus(AddRec(Start=0,Step=3)[0],3), i8), i32),3) >

Dan, Thanks for the response ... On 12/17/2012 1:53 PM, Dan Gohman wrote: > On Mon, Dec 10, 2012 at 2:13 PM, Matthew Curtis <mcurtis at codeaurora.org> wrote: >> Hello all, >> >> I wanted to get some feedback on this patch for ScalarEvolution. >> >> It addresses a performance problem I am seeing for simple benchmark. >> >> Starting with this C

+CC llvm-dev On Tue, May 8, 2018 at 2:34 AM, Gal Zohar <Gal.Zohar at ceva-dsp.com> wrote: > I noticed that SCEV, when trying to perform strength reduction, doesn’t use > the ability to prove an induction variable does not signed/unsigned wrap due > to infinite loops. > > Is there an easy way to use the isAddRecNeverPoison function when > determining if strength reduction

Hi Hal, In that case what is the best way to query whether there is a loop carried dependence between B[j] and A[j] at i-loop level? We were operating under the assumption of 'conservatively correct' behavior of alias analysis in the function scope? Thanks, Pankaj From: Finkel, Hal J. <hfinkel at anl.gov> Sent: Tuesday, March 17, 2020 11:50 AM To: Hiroshi Yamauchi <yamauchi at

Hi Sanjoy, Thanks for the reply! Your approach sounds good to me! I think 1) is legal as address wraparound in unsigned range doesn't make sense given a positive offset, but I am not sure. I think umax will not be added if we can prove the predicate as known. I am not sure whether umax will get simplified if we add nuw to the expressions. -Pankaj -----Original Message----- From: Sanjoy

Hi Pankaj, On April 14, 2017 at 4:55:16 PM, Chawla, Pankaj (pankaj.chawla at intel.com) wrote: > I have attached the IR I got by compiling with -O2. This is just before we widen the IV. Thanks! > To get the backedge taken count info I ran indvars on it and then replaced zext with sext. > > I think regardless of where we decide to add this transformation in the pipeline, it should

Thanks for the suggestion but datalayout info did not solve the problem! -Pankaj -----Original Message----- From: Philip Reames <listmail at philipreames.com> Sent: Tuesday, August 20, 2019 5:26 PM To: Chawla, Pankaj <pankaj.chawla at intel.com>; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] missing simplification in ScalarEvolution? Try adding a datalayout with pointer size

My understanding is that alias analysis returns results in the function scope, not in loop scope. Since both the phis access both global arrays, that should results in BasicAA conservatively returning MayAlias. I debugged this a little bit and narrowed it down to the section of the code in BasicAAResult::aliasPHI() which has this comment- // Analyse the PHIs' inputs under the assumption

As far Am Mi., 18. März 2020 um 11:34 Uhr schrieb Chawla, Pankaj <pankaj.chawla at intel.com>: > >> There seems to be a bug in DI, see Felipe's answer. > Maybe I missed something. There seems to be no resolution to the problem. How can DA fix this without help from alias analysis? DependenceInfo is not using the AA interface correctly. Either DI has to be fixed, or another

Thanks for the helpful reply! I see that we are trying to keep ScalarEvolution stable around instruction ordering. My suggestion would be to not restrict the fix by only recursing on the first operand. By "dominator logic" I meant that if all other 'cheap' checks fail, we should decide by walking the dominator tree to see which instruction's basic block is encountered

Am Mi., 18. März 2020 um 18:15 Uhr schrieb Chawla, Pankaj <pankaj.chawla at intel.com>: > > >> DependenceInfo is not using the AA interface correctly. Either DI has to be fixed, or another method added to AA that gives additional guarantees. Please see the bug report for details. > > Thanks for updating the bug report but GetUnderlyingObject() doesn't help in this case.

Am Di., 17. März 2020 um 16:56 Uhr schrieb Chawla, Pankaj via llvm-dev <llvm-dev at lists.llvm.org>: > All I am expecting from DA is a direction vector containing (*). There seems to be a bug in DI, see Felipe's answer. > I think the main problem is that currently there is no exact way DA can query AliasAnalysis in a ‘conservatively correct’ manner. > > Using UnknownSize