search for: delinearized

.... I believe that the current implementation of delinearization is based on this paper: http://web.cse.ohio-state.edu/~pouchet.2/doc/ics-article.15a.pdf. This paper describes how to delinearize the subscripts, and as a last step it requires certain conditions to be met in order to validate that the delinearized indexes are correct. The `tryDelinearize` function in `DependenceAnalysis.cpp` appears to be checking for cases where these conditions can be validated *at compile time*: ``` // Statically check that the array bounds are in-range. The first subscript we // don't have a size for and it cann...

...q7oP3ZSUVc4BemvrVo&m=46eKxI_sFjjeBzn7X-OLXSEUwHN-HVCD16TF9OuyIqc&s=nraVp9R56UlYi0We27kmGSjZGnM296r0HFpbRR62Fzs&e= > . > > This paper describes how to delinearize the subscripts, and as a last step > it requires certain conditions to be met in order to validate that the > delinearized indexes are correct. The `tryDelinearize` function in > `DependenceAnalysis.cpp` appears to be checking for cases where these > conditions can be validated *at compile time*: > > ``` > // Statically check that the array bounds are in-range. The first subscript > we > // don...

...= 4; >        } >    } > } > Needs to not get the dependency vector [0 >], otherwise unroll and jam might think it was safe to reorder (unroll and jam) and miscompile the code. Without the delinearization validity checks, the access functions A[i*M + j] and A[i*M + j - 1] would get delinearized as follows: SrcSCEV = {{((4 * %M) + %A)<nsw>,+,(4 * %M)}<%for.body>,+,4}<%for.body4> DstSCEV = {{(-4 + (4 * %M) + %A),+,(4 * %M)}<%for.body>,+,4}<%for.body4> SrcSubscripts: {1,+,1}<%for.body>{0,+,1}<%for.body4> DstSubscripts: {1,+,1}<%for.body>{-1,+...

...aihobyOnVzXW7OPSK1-NiSYQkq7oP3ZSUVc4BemvrVo&m=46eKxI_sFjjeBzn7X-OLXSEUwHN-HVCD16TF9OuyIqc&s=nraVp9R56UlYi0We27kmGSjZGnM296r0HFpbRR62Fzs&e= . This paper describes how to delinearize the subscripts, and as a last step it requires certain conditions to be met in order to validate that the delinearized indexes are correct. The `tryDelinearize` function in `DependenceAnalysis.cpp` appears to be checking for cases where these conditions can be validated *at compile time*: ``` // Statically check that the array bounds are in-range. The first subscript we // don't have a size for and it cannot o...

On Wed, Sep 19, 2018 at 4:58 AM Venkataramanan Kumar < venkataramanan.kumar.llvm at gmail.com> wrote: > Hi, > > I tired to see when this behavior changed in LLVM. > It seems to start from. > --snip-- > commit 95e5d37d5868ebde2302bc302c1e0af407c5646d > Author: Sebastian Pop <sebpop at gmail.com> > Date: Tue Mar 6 21:55:59 2018 +0000 > > DA: remove

[CC bollu, mferguson, shil] Am Do., 23. Mai 2019 um 17:13 Uhr schrieb Bardia Mahjour < bmahjour at ca.ibm.com>: > Thanks David and Michael for the clarification. > > I think I understand the rational behind those checks in delinearization > now. > > > Some other languages have stronger guarantees about their array > dimensions accesses being in range. But this being

Hi Ees, SCEV Delinearization is the closest I know. But it has its problems. Well for one your expression should be SCEVable. But more importantly, SCEV Delinearization is trying to deduce something that is high-level (actually source-level) from a low-level IR in which a lot of this info has been lost. So, since there's not a 1-1 mapping from high-level code to LLVM IR, going backwards will

Michael makes a great point about aliasing here and different indexing that accesses the same element! Another note: x = A[0][2] is fundamentally different depending on the type of `A`. If e.g. A was declared: int A[10][20], there's only _one_ load. A is a (and is treated as) a linear buffer, and GEPs only pinpoint the specific position of A[0][2] in this buffer (i.e. 0*10 + 2). But if A was

LLVM friends, I'm currently trying to make LoopVectorizationLegality class in Transform/Vectorize/LoopVectorize.cpp more modular and eventually move it to Analysis directory tree. It uses several file scope helper functions that do not really belong to LoopVectorize. Let me start from getPointerOperand(). Within LLVM, there are five other similar functions defined. I think it's time to

Hi everyone, I've been using SCEV Delinearization but it fails when other-than-pointer-size values are used in the subscripts. To make that clear, say that we have a target in which pointers are 64-bit for (int32_t i ...) for (int32_t j ...) a[i][j] = ... doesn't work while this: for (int64_t i ...) for (int64_t j ...) does work. I assume that the former does not work because

I just checkout release_38 branches of llvm, clang and polly and built it on and x86 Ubuntu with cmake: CMAKE_BUILD_TYPE="Debug" CMAKE_INSTALL_PREFIX="$HOME/toolchain/install/llvm-3.8" LLVM_TARGETS_TO_BUILD="X86" cmake -G "Unix Makefiles" \ -DBUILD_SHARED_LIBS="ON" \ -DCMAKE_BUILD_TYPE=$CMAKE_BUILD_TYPE \

"Saito, Hideki via llvm-dev" <llvm-dev at lists.llvm.org> writes: > LLVM friends, > > I'm currently trying to make LoopVectorizationLegality class in > Transform/Vectorize/LoopVectorize.cpp more modular and eventually move > it to Analysis directory tree. It uses several file scope helper > functions that do not really belong to LoopVectorize. Let me start

Erkan, you're right. Sorry about that. Attached is the most recent version. Preston Hi Preston, > I am trying to use DA as well. I used your example and commands that you > wrote in order to get DA information. > However, it does not report any dependence info. > I am wondering whether your local copy differs from the one on the > repository ? > Thanks. > Erkan.

Hi Michael, Thanks for the reply. I've seen but have not used it. FWIW, the problem is not how to generate the runtime checks (although it'd be good if we can get it for free), but how to clean up the SCEVs. Does PSE do that ? Cheers, Stefanos Στις Δευ, 21 Σεπ 2020 στις 11:59 π.μ., ο/η Michael Kruse < llvmdev at meinersbur.de> έγραψε: > Have you looked into

Hi all, Unfortunately, all my Hunks are failed when I apply : patch -p1 < da.patch command. The problem might be due to the fact that da.patch file was created against revision 167549, but I am on revision 167719 (I believe the most recent one). I am not sure if this cause the problem ? But Preston may I ask you to generate the patch file against revison 167719 ? Thanks in advance. On

What LoopVectorize.cpp has are the following. Each function may have to have a separate consolidation discussion. I'm bringing up getpointerOperand() since I actually found multiple instances defined/used. DependenceAnalysis.cpp has isLoadOrStore(). LoopAccessAnalysis.cpp has getAddressSpaceOperand(). I'm sure there are others that might be worth discussing within this thread or a follow

Preston, thanks for the explanation and patch. Now it's printing the direction and distance values. On Tue, Nov 13, 2012 at 12:22 PM, Preston Briggs <preston.briggs at gmail.com>wrote: > Erkan, you're right. Sorry about that. > Attached is the most recent version. > > Preston > > > > Hi Preston, >> I am trying to use DA as well. I used your example

Hi all, Apparently some people had trouble joining today. I also had trouble using the attendee ID provided by webex. I've canceled the meeting series and will be scheduling a new one with an updated link. Please remember to update your calendars with the new invite. My apologies to those who couldn't join today, and to everyone for the churn. Today's Meeting Minutes:

Hello, We would like to begin discussions around a new set of intrinsics, to better express multi-dimensional array indexing within LLVM. The motivations and a possible design are sketched out below. Rendered RFC link here <https://github.com/bollu/llvm-multidim-array-indexing-proposal/blob/master/RFC.md> Raw markdown: # Introducing a new multidimensional array indexing intrinsic ## The

--------------------------- Wed, Sep 11, 2019: --------------------------- - LICM vs Loop Sink Strategy (Whitney) - LICM and SCEV expander host code with no regards to increased live-ranges. This is a long standing issue where historically preference has been to keep LICM more aggressive. - Two questions from IBM side: a. This problem is not specific to the POWER