search for: loopversioning

...y access in loop body. 3) Clone original loop and set all memory access as no-alias in new loop. 4) Set original loop & versioned loop as a branch target of runtime check result. 5) Call LICM on aggressive alias versioned of loop(For now LICM is scheduled later and not directly called from LoopVersioning pass). Consider following test: 1 int foo(int * var1, int * var2, int * var3, unsigned itr) { 2 unsigned i = 0, j = 0; 3 for(; i < itr; i++) { 4 for(; j < itr; j++) { 5 var1[j] = itr + i; 6 var3[i] = var1[j] + var3[i]; 7 }...

...y. > 3) Clone original loop and set all memory access as no-alias in new loop. > 4) Set original loop & versioned loop as a branch target of runtime check result. > 5) Call LICM on aggressive alias versioned of loop(For now LICM is scheduled later and not directly > called from LoopVersioning pass). > > Consider following test: > > 1 int foo(int * var1, int * var2, int * var3, unsigned itr) { > 2 unsigned i = 0, j = 0; > 3 for(; i < itr; i++) { > 4 for(; j < itr; j++) { > 5 var1[j] = itr + i; > 6...

> On Mar 3, 2015, at 1:29 AM, Nema, Ashutosh <Ashutosh.Nema at amd.com <mailto:Ashutosh.Nema at amd.com>> wrote: > > Hi Adam, > > Thanks for looking into LoopVersioning work. > > I have gone through recent LoopAccessAnalysis changes and found some of the stuff > overlaps (i.e. runtime memory check, loop access analysis etc.). LoopVersioning can > use some of the things from LAA. > > LoopVersioning is a memory check based multi versioning opt...

...anjoy Das - Azul Systems, Philip Reames - Azul Systems LLVM back end for HHVM/PHP, Brett Simmers - Facebook, Inc., Maksim Panchenko - Facebook, Inc Session #9: October 30 2:00-3:30: Salon I & II Throttling Automatic Vectorization: When Less Is More, Vasileios Porpodas - University of Cambridge LoopVersioning LICM, Ashutosh Nema - AMD Session #10: October 30 4:30-6:00 Salon III & IV Compiling large, real-world codebases with clang on Windows, Hans Wennborg - Google Inc., Nico Weber - Google Inc. Advances in Loop Analysis Frameworks and Optimizations, Adam Nemet - Apple Inc, Michael Zolotukhin - Ap...

...ad only pointers intersect. > 2) Only need to check pointers between two different dependency sets. > 3) Only need to check pointers in the same alias set > > I’m sure if we like this to be used by other optimization then not all optimization appreciate > above checks. Specifically LoopVersioning does not care about this, it expects all the pointers > in a loop should be considered for a memory check. Also it does not care about different > dependency set & different alias sets. > > I suggest we can make these checks optional, and give flexibility to users of this class to...

Dear LLVM community, LLVM IR has a concept of 'LoopID' [1] which is a misnomer: (a) LoopIDs are not unique: Any pass that duplicates IR will do it including its metadata (e.g. LoopVersioning) such that thereafter multiple loops are linked with the same LoopID. There is even a test case (Transforms/LoopUnroll/unroll-pragmas-disabled.ll) for multiple loops with the same LoopID. (b) LoopIDs are not persistent: Adding or removing an item from a LoopID can only be done by creating a new MD...

...ugs at nondot.org NEW --- [StructurizeCFG] lit test hits assert > in verifyDomTree when compiled w/ XDEBUG > <https://llvm.org/bugs/show_bug.cgi?id=27488> 14:34:06 > 27487 <https://llvm.org/bugs/show_bug.cgi?id=27487> librarie Scalar O > unassignedbugs at nondot.org NEW --- [LoopVersioning] lit test hits invalid > domtree assert w/ XDEBUG <https://llvm.org/bugs/show_bug.cgi?id=27487> > 14:31:56 > 27486 <https://llvm.org/bugs/show_bug.cgi?id=27486> librarie Scalar O > unassignedbugs at nondot.org NEW --- [InductiveRangeCheckElimination] > invalidates domtree...

Yeah, they are just triggered by lit check tests. I’ll file some bugs today, though it looks like Quentin may have already filed bugs for some of these. -- Geoff Berry Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project From: Daniel Berlin [mailto:dberlin at dberlin.org] Sent: Friday,

...l void @_z10exit_usagepkc unreachable // because exit_usage is no-return } } In this case c happens to be equal to c1, in which case I guess some pass removes the inner inner conditional because it is always true. How do you think code versioning in general should handle this? I looked into LoopVersioning.cpp (used by LLVM's vectorizer), but could not see how it handles this situation. Maybe it is not affected because lifetime markers usually do not cross loop bounds. Michael

...es >>>> (e.g. the LoopVectorizer’s dependence analysis + loop >>>> versioning analysis into a stand-alone analysis pass >>>> (LoopAccessAnalysis)) and then build new transformations (e.g. >>>> LoopDistribution, LoopLoadElimination, LICMLoopVersioning) on >>>> top of these. >>>> >>>> The idea was that infrastructure would be incrementally >>>> improved from two directions: >>>> >>>> - As new transformations are built analyses have to be improved >>>&...

...far to incrementally improve > and generalize the required analyses (e.g. the LoopVectorizer’s dependence > analysis + loop versioning analysis into a stand-alone analysis pass > (LoopAccessAnalysis)) and then build new transformations (e.g. > LoopDistribution, LoopLoadElimination, LICMLoopVersioning) on top of these. > > The idea was that infrastructure would be incrementally improved from two > directions: > > - As new transformations are built analyses have to be improved (e.g. past > improvements to LAA to support the LoopVersioning utility, future > improvements for fu...

...crementally > improve and generalize the required analyses (e.g. the > LoopVectorizer’s dependence analysis + loop versioning analysis into a > stand-alone analysis pass (LoopAccessAnalysis)) and then build new > transformations (e.g. LoopDistribution, LoopLoadElimination, > LICMLoopVersioning) on top of these. > > The idea was that infrastructure would be incrementally improved from > two directions: > > - As new transformations are built analyses have to be improved (e.g. > past improvements to LAA to support the LoopVersioning utility, future > improvements for...

...tally >> improve and generalize the required analyses (e.g. the LoopVectorizer’s >> dependence analysis + loop versioning analysis into a stand-alone analysis >> pass (LoopAccessAnalysis)) and then build new transformations (e.g. >> LoopDistribution, LoopLoadElimination, LICMLoopVersioning) on top of these. >> >> The idea was that infrastructure would be incrementally improved from two >> directions: >> >> - As new transformations are built analyses have to be improved (e.g. >> past improvements to LAA to support the LoopVersioning utility, future...

...pendence analysis + loop >>>>> versioning analysis into a stand-alone analysis pass >>>>> (LoopAccessAnalysis)) and then build new transformations >>>>> (e.g. LoopDistribution, LoopLoadElimination, >>>>> LICMLoopVersioning) on top of these. >>>>> >>>>> The idea was that infrastructure would be incrementally >>>>> improved from two directions: >>>>> >>>>> - As new transformations are built analyses have to be >>&gt...

...hed direction was so far to incrementally improve and generalize the required analyses (e.g. the LoopVectorizer’s dependence analysis + loop versioning analysis into a stand-alone analysis pass (LoopAccessAnalysis)) and then build new transformations (e.g. LoopDistribution, LoopLoadElimination, LICMLoopVersioning) on top of these. >> >> The idea was that infrastructure would be incrementally improved from two directions: >> >> - As new transformations are built analyses have to be improved (e.g. past improvements to LAA to support the LoopVersioning utility, future improvements for...

2017-03-31 13:46 GMT+02:00 Daniel Berlin <dberlin at dberlin.org>: > > > On Fri, Mar 31, 2017 at 4:05 AM, Michael Kruse <llvmdev at meinersbur.de> > wrote: >> >> 2017-03-31 1:16 GMT+02:00 Daniel Berlin <dberlin at dberlin.org>: >> > if you transformed >> > >> > lifetime.start(%p) >> > use %p >> >

...neralize the required analyses (e.g. the >>> LoopVectorizer’s dependence analysis + loop versioning analysis into >>> a stand-alone analysis pass (LoopAccessAnalysis)) and then build new >>> transformations (e.g. LoopDistribution, LoopLoadElimination, >>> LICMLoopVersioning) on top of these. >>> >>> The idea was that infrastructure would be incrementally improved >>> from two directions: >>> >>> - As new transformations are built analyses have to be improved >>> (e.g. past improvements to LAA to support the LoopV...

...ater than 32. [r259419](http://reviews.llvm.org/rL259419). * The ability to emit errors from the backend for unsupported features has been refactored, so BPF, WebAssembly, and AMDGPU backends can all share the same implementation. [r259498](http://reviews.llvm.org/rL259498). * A simple pass using LoopVersioning has been added, primarily for testing. The new pass will fully disambiguate all may-aliasing memory accesses no matter how many runtime checks are required. [r259610](http://reviews.llvm.org/rL259610). * The way bitsets are used to encode type information has now been documented. [r259619](http://...

...mpilation and would like to see it used on a daily basis by just choosing an optimization level. IMHO we should avoid multiple loop optimizations in LLVM. If each of them does its own loop versioning, we will get multiple redundant runtime checks and code duplication. This is already the case with LoopVersioningLICM, LoopDistribution, LoopVectorizer and LoopLoadElimination. I argue for a more integrated approach for loop-based optimizations. To clarify, what this is not: - It has not been shown to work in practice. - While I would like to contribute to implement such a loop optimizer, this is not somethin...

...far to incrementally improve > and generalize the required analyses (e.g. the LoopVectorizer’s dependence > analysis + loop versioning analysis into a stand-alone analysis pass > (LoopAccessAnalysis)) and then build new transformations (e.g. > LoopDistribution, LoopLoadElimination, LICMLoopVersioning) on top of these. > > The idea was that infrastructure would be incrementally improved from two > directions: > > - As new transformations are built analyses have to be improved (e.g. past > improvements to LAA to support the LoopVersioning utility, future > improvements for fu...