similar to: [LLVMdev] new methods for ScalarEvolutions

Some optimizations depend on whether alloca instruction always has non-zero value. Currently, this checking is done by isKnownNonZero() in ValueTracking, and it assumes alloca in address space 0 always has non-zero value but alloca in non-zero address spaces does not always have non-zero value. However, this assumption is incorrect for certain targets. For example, amdgcn---amdgiz target has

Hal, Thanks for your suggestion. I think that makes sense. Currently, non-zero alloca address space is already represented by data layout, e.g., the last component of the data layout of amdgcn---amdgiz target is -A5, which means alloca is in address space 5. How about adding a letter z to -A5 to indicate alloca may have zero value? i.e. -A5 means alloca is in address space 5 and always has

Hi Max, On Wed, Jan 24, 2018 at 10:03 PM, Maxim Kazantsev via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I want to raise a discussion about reasonability of late setting of > nsw/nuw/nw flags to SCEV AddRecs through setNoWrapFlags method. A discussion > about this have already happened in August last year, there was a concern > about different no-wrap flags that come from

Hi, I'm currently trying to implement [1] basic loop-dependence analysis for LLVM (since most of the symbol handling code is already there in SCEV) and I'm facing the following issues: Let's say we have a loop void test(int *array, unsigned long length) { for (unsigned long i = 0; i < length; i++) array[3 * length - i] = array[i]; } For there to be a loop carried

Hi, i am playing the ScalarEvolution these days. i found the the ScalarEvolution will simply return a SCEVUnknow for a ICmpInst, so i think maybe great to add a new kind of SCEV to the ScalarEvolution framework. for example, if i run ScalarEvolution on the bc file generate from the following C source file: int f(int a, int b, int c, int d) { return (2 * a + 5 * c + 2) > (4 * d - 3*b

Be careful about oversimplifying signed integer comparisons -- integer arithmetic can easily overflow, so you cannot transform A > B to A - B > 0. The compare instructions in most processors do not simply subtract and test the most significant bit; they compute what the sign of the difference would be in extended precision. On Apr 17, 2010, at 1:00 PM, llvmdev-request at cs.uiuc.edu wrote:

On Thu, Jan 25, 2018 at 9:55 PM, Maxim Kazantsev <max.kazantsev at azul.com> wrote: > I don't really believe that option 2 may work just because even if we recalculate the range for this add recurrency, there are already its derivatives with cached ranges (the most obvious example is sext and expressions where this sext is involved). We can speculate about what is "simple

Hi all, I have been looking at the `DependenceAnalysis` pass in `llvm/include/llvm/Analysis/DependenceAnalysis.h`. In order for this analysis to produce accurate dependence vectors for multi-dimensional arrays in nested loops, it needs to "delinearize" array element accesses to recover the subscripts in each dimension of the array. I believe that the current implementation of

Thanks for your insides Sanjoy! I don't really believe that option 2 may work just because even if we recalculate the range for this add recurrency, there are already its derivatives with cached ranges (the most obvious example is sext and expressions where this sext is involved). We can speculate about what is "simple enough" to not cache the ranges, but I believe that there is

Hi David, Thank you very much for your response. I also get correct results for my example (for a 64-bit target) if the upper bounds are changed to unsigned. The reason is simply because clang zero-extends `m` for address calculations but sign-extends it for the loop upper bound. This prevents SCEV from canceling out the 'm' term from the difference expression that looks like `(-3 +

Hello Under the proviso that it's been a while since I looked into any of these things... On 05/15, Bardia Mahjour via llvm-dev wrote: > I also get correct results for my example (for a 64-bit target) if the upper > bounds are changed to unsigned. The reason is simply because clang zero-extends > `m` for address calculations but sign-extends it for the loop upper bound. This >

Hello Yes, I agree that the SCEV cannot be simplified. Is my understanding correct that it is passed to a function like "isKnownNegative"? Which could still be able to prove is always true. The delinearisation may be valid, depending on exactly how you define delinearisation (under what conditions it should be giving results). It would be invalid for DA to return a dependency of [0

Hello Everyone, I want to raise a discussion about reasonability of late setting of nsw/nuw/nw flags to SCEV AddRecs through setNoWrapFlags method. A discussion about this have already happened in August last year, there was a concern about different no-wrap flags that come from different sequences of SCEV flags invocations. It was mentioned there that late setting of flags is actually a hack to

hello all, A small patch that fixes Query get_description in testsute3.py. see the attachment. -- Best Regards, Xiaona Han -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xapian.org/pipermail/xapian-devel/attachments/20120409/18a07efb/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name:

On 8/8/2017 1:37 PM, Friedman, Eli wrote: > On 8/8/2017 10:22 AM, Geoff Berry via llvm-dev wrote: >> Hi all, >> >> I'm looking into resolving a FIXME in the LoopDataPrefetch (and FalkorMarkStridedAccesses) pass by marking both of these passes as preserving the ScalarEvolution analysis. Unfortunately, when this change is made, LSR will generate different code. One of the

Hi all, I'm looking into resolving a FIXME in the LoopDataPrefetch (and FalkorMarkStridedAccesses) pass by marking both of these passes as preserving the ScalarEvolution analysis. Unfortunately, when this change is made, LSR will generate different code. One of the root causes seems to be that SCEV will return different nsw/nuw flags for the same Value, depending on what order the

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:

Hi, all. I'm adding a new pass in opt. To make the debugging easier, I'm trying to draw the CFG before and after the new pass. Is there any an option to dump the .bc file before/after a specific opt pass? Thanks. Xiaoming -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hello all, I’m pretty new to LLVM. I'm writing a pass for loop optimization. I clone and rearrange loops, setting the cloned loop as the original loop’s parent. This can be done multiple times, until there is no more work to do. The trouble is, after the first time I do this, the cloned loop's SCEVs become unknown types when they should be AddRecExpr. If I re-run the whole pass on the

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