search for: isloopentryguardedbycond

...include/generated/asm-offsets.h 聽 CALL聽聽聽聽scripts/checksyscalls.sh 聽 DESCEND聽聽objtool 聽 CHK聽聽聽聽聽scripts/mod/devicetable-offsets.h 聽 CHK聽聽聽聽聽include/generated/compile.h 聽 CC聽聽聽聽聽聽arch/x86/events/core.o clang-7.0: /home/dwmw2/git/llvm/lib/Analysis/ScalarEvolution.cpp:9092: bool llvm::ScalarEvolution::isLoopEntryGuardedByCond(const llvm::Loop*, llvm::CmpInst::Predicate, const llvm::SCEV*, const llvm::SCEV*): Assertion `(!ProvedNonStrictComparison || !ProvedNonEquality) && "Why we were unable to prove (Pred, LHS, RHS) via constant ranges?"' failed. #0 0x0000000003cdcc0e llvm::sys::PrintStackTrace(ll...

...not interfere with the optimizer). Thinking to custom > intrinsics I don't understand how to allow memory optimizations and, at the same > time, prevent the intrinsic elimination or hoisting from the target loop. > > I would appreciate any hint on this topic. See ScalarEvolution::isLoopEntryGuardedByCond. It's part of the analysis that we use to determine trip count and benefits from rotated loops. LLVM never annotates the IR with a history of transformations. You could potentially annotate the LoopInfo analysis, but it will only be preserved within the same LoopPassManager (you would have to...

...y know the difference is 4*k and k > 0. Isn’t > that enough? Is the problem that 4*k may overflow? Ah, I forgot to explain, one problem is that I can't divide {((4 * %k) + %a),+,4}<%for.body> by 4 to get ride of the type size. I was trying to do this in order to make it easier for isLoopEntryGuardedByCond to match the condition, but even dividing by 4 does not work if the recurrence is not <nsw> (as far as I can tell). > > Maybe this sort of alias analysis needs to reason about array > indices, not addresses. Being able to divide by the type sizes would make this easier ;) Thanks...

I've landed the patch in r324449. Before we merge this into two different Clang release branches and almost immediately release one of them, I would really like someone to confirm that this patch works well with the Linux kernel. David, if you're up for that, it would be great. Alternatively, Guenter or someone else here can help. On Tue, Feb 6, 2018 at 5:59 PM Chandler Carruth

...ckground on the concurrent memory model. So, is it sufficient that the loop entry is guarded by condition (cbz at top) for preventing the race? The loop entry will be guarded by condition if loop has been rotated by loop rotate pass. Since LICM runs after loop rotate, we can use ScalarEvolution::isLoopEntryGuardedByCond to check if we can speculatively execute load without causing a race. Is it heavy-handed solution for this problem? I can create a bug if you would like to. Thanks, Balaram From: Robin Morisset [mailto:morisset at google.com] Sent: Tuesday, September 02, 2014 7:40 PM To: Filip Pizlo Cc: Balaram...

Dear all, I'm working on a late IR target dependent optimization on loops. A part of this optimization requires to derive "by hand" the trip-count expression of a given loop. In order to handle correctly these cases I need to check if the loop has an entry guard or not. The problem I have is that starting from the information I derive during my analysis (initial IV value, last IV

...ptimizer). Thinking to custom >> intrinsics I don't understand how to allow memory optimizations and, at the same >> time, prevent the intrinsic elimination or hoisting from the target loop. >> >> I would appreciate any hint on this topic. > > See ScalarEvolution::isLoopEntryGuardedByCond. It's part of the analysis that we use to determine trip count and benefits from rotated loops. > > LLVM never annotates the IR with a history of transformations. You could potentially annotate the LoopInfo analysis, but it will only be preserved within the same LoopPassManager (you woul...

Your reasoning sounds correct to me. Let's revert for now? I don't think there is an easy fix, we'll have to do a global "must be executed" analysis to reapply the patch soundly. And that's difficult since any external functional call can call "exit(0)". -- Sanjoy On Thu, Sep 26, 2019 at 6:19 AM Tim Northover <t.p.northover at gmail.com> wrote: >

...stom >>> intrinsics I don't understand how to allow memory optimizations and, at the same >>> time, prevent the intrinsic elimination or hoisting from the target loop. >>> >>> I would appreciate any hint on this topic. >> >> See ScalarEvolution::isLoopEntryGuardedByCond. It's part of the analysis that we use to determine trip count and benefits from rotated loops. >> >> LLVM never annotates the IR with a history of transformations. You could potentially annotate the LoopInfo analysis, but it will only be preserved within the same LoopPassManager (...

On Oct 31, 2013, at 1:24 PM, Hal Finkel <hfinkel at anl.gov> wrote: > Andy, et al., > > If I start with C code like this: > > void foo(long k, int * restrict a, int * restrict b, int * restrict c) { > if (k > 0) { > for (int i = 0; i < 2047; i++) { > a[i] = a[i + k] + b[i] * c[i]; > } > } > } > > Clang -O3 will produce code like

Andy, et al., If I start with C code like this: void foo(long k, int * restrict a, int * restrict b, int * restrict c) { if (k > 0) { for (int i = 0; i < 2047; i++) { a[i] = a[i + k] + b[i] * c[i]; } } } Clang -O3 will produce code like this: entry: %cmp = icmp sgt i64 %k, 0 br i1 %cmp, label %for.body.preheader, label %if.end for.body.preheader: br label

On Tue, Jan 24, 2017 at 1:20 PM, Sanjay Patel via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > I started looking at the log files that you attached, and I'm confused. > The code that is supposedly causing the perf regression is created by the > loop vectorizer, right? Except the bad code is not in the "vector.body", so > is there something peculiar about

I think gcc is right. It inserted a branch for n == 0 (the cbz at the top), so that's not a problem. In all other regards, this is safe: if you examine the sequence of loads and stores, it eliminated all but the first load and all but the last store. How's that unsafe? If I had to guess, the bug here is that LLVM doesn't want to hoist the load over the condition (which it is right