search for: comparescevcomplexity

...pretty sure is that is there guarantee to exist dominance relation on their loop predecessor blocks. That is, either LPred dominates RPred or RPred dominate LPred? B.R. - Min On Tue, Jun 11, 2019 at 8:41 PM Michael Kruse <llvmdev at meinersbur.de> wrote: > Hi, > > if I understand CompareSCEVComplexity correctly, we just need some > deterministic order, not that important which one. We have three > cases: > > 1. LHead dominates RHead > 2. RHead dominates LHead > 3. There is no dominance relationship between the loops > > LHead dominating RHead can either mean that R is ne...

Hi, Recently I got a crash when I tried to analysis a program with ScalarEvolution AliasAnalysis(SCEV-AA for short). It turns out to be a (possibly) incorrect assertion inside the CompareSCEVComplexity routine. The simplest solution would be just remove that assertion but I also found that the surrounding logics on calculating SCEV cost seems to be incorrect either. Thus I want to discuss with you folks about the best way to solve this. Here are the details: Setup Off-the-tip llvm-project, incl...

...d here https://reviews.llvm.org/D75628#inline-689527. Basically in this case, the dependence equation requires us to symbolically create an expression involving two or more recurrences that recur with non-dominating loops (sibling loops). Currently creating such a SCEV expression trips asserts in `CompareSCEVComplexity()` and ` isKnownViaInduction()` saying that a given SCEV expression cannot be composed of recurrences that have no dominance relationship between them. Michael tried explaining to me why there is this restriction about dominance, and I'm beginning to understand why such restriction may be nece...

...wn %q.012. The easiest way to reproduce the issue is to apply the attached se.patch to the compiler which changes the print function of ScalarEvolution to print in this particular order and then execute this- $ opt -analyze -scalar-evolution gep-phi.ll The root cause of this issue is the function CompareSCEVComplexity(). The ordering for instruction operands is not very robust as acknowledged by the comment for this particular piece of code- // For instructions, compare their loop depth, and their operand // count. This is pretty loose. Can this be fixed? Thanks, Pankaj -------------- next part --------------...

...two sibling loops with the same parent, one will frequently, but not always dominate the other.  Can you give a specific example of when forming a recurrence between two siblings (without one dominating the other), is useful? Currently creating such a SCEV expression trips asserts in ` CompareSCEVComplexity()` and `isKnownViaInduction()` saying that a given SCEV expression cannot be composed of recurrences that have no dominance relationship between them. Michael tried explaining to me why there is this restriction about dominance, and I'm beginning to understand why such...

...loops with the same parent, one will frequently, but not always dominate the other. Can you give a specific example of when forming a recurrence between two siblings (without one dominating the other), is useful? Currently creating such a SCEV expression trips asserts in ` CompareSCEVComplexity()` and `isKnownViaInduction()` saying that a given SCEV expression cannot be composed of recurrences that have no dominance relationship between them. Michael tried explaining to me why there is this restriction about dominance, and I'm beginning...

...arent, one will frequently, but not always dominate the other. Can you give a specific example of when forming a recurrence between two siblings (without one dominating the other), is useful? Currently creating such a SCEV expression trips asserts in `CompareSCEVComplexity()` and ` isKnownViaInduction()` saying that a given SCEV expression cannot be composed of recurrences that have no dominance relationship between them. Michael tried explaining to me why there is this...

...uce the issue is to apply the attached > se.patch to the compiler which changes the print function of > ScalarEvolution to print in this particular order and then execute > this- > > $ opt -analyze -scalar-evolution gep-phi.ll > > The root cause of this issue is the function CompareSCEVComplexity(). > The ordering for instruction operands is not very robust as > acknowledged by the comment for this particular piece of code- > > // For instructions, compare their loop depth, and their operand > > // count. This is pretty loose. > > Can this be fixed? > > Thank...