similar to: [LLVMdev] getelementptr and SCEVs

On Fri, 23 Feb 2007, Dan Gohman wrote: > I'm experimenting a bit with the SCEV code and one of the problems I'm > facing is that there's no way to represent a getelementptr operation as a > SCEV. Right. SCEV is really designed to expression integer equations. > The obvious way to do this in the existing SCEV framework is to add > a new SCEV subclass. I started doing

On Fri, Feb 23, 2007 at 06:34:47PM -0800, Chris Lattner wrote: > On Fri, 23 Feb 2007, Dan Gohman wrote: > > Does anyone have any suggestions on the best way to procede? It may be > > easier at this point to go back to a multiple-index getelementptr SCEV > > class, and just write the code to work with it. > > It really depends on what you're trying to do. Can you

On Feb 23, 2012, at 8:20 AM, David Greene wrote: > I have a few enhancements to SCEV to help it identify more types of > recurrences. I want to send these upstream but I need a little > feedback. > > I've added ptrtoint and inttoptr SCEV expressions so that recurrences > involving these constructs can be recognized. However, this scary > comment gives me pause: >

Dan Gohman <gohman at apple.com> writes: >> These enhancements are critical for us because of the way our frontends >> work (less than ideal but we have to deal with it), due to some language >> quirks (casting in C, odd Fortran constructs, etc.) and because users >> sometimes stretch the boundaries of good taste :). >> >> Is this a reasonable approach?

Hi, I noticed an inconsistency in how ScalarEvolution orders instruction operands. This inconsistency can result in creation of separate (%a * %b) and (%b * %a) SCEVs as demonstrated by the example IR below (attached as gep-phi.ll)- target datalayout = "e-m:e-p:32:32-f64:32:64-f80:32-n8:16:32-S128" define void @foo(i8* nocapture %arr, i32 %n, i32* %A, i32* %B) local_unnamed_addr {

I have a few enhancements to SCEV to help it identify more types of recurrences. I want to send these upstream but I need a little feedback. I've added ptrtoint and inttoptr SCEV expressions so that recurrences involving these constructs can be recognized. However, this scary comment gives me pause: // It's tempting to handle inttoptr and ptrtoint as no-ops, however this can //

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

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

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 folks, I'm trying to analyse this piece of IR: for.body: ; preds = %for.body, %entry %indvars.iv = phi i64 [ 0, %entry ], [ %indvars.iv.next, %for.body ] %0 = shl nsw i64 %indvars.iv, 1 %arrayidx = getelementptr inbounds i32* %b, i64 %0 %1 = load i32* %arrayidx, align 4, !tbaa !1 %add = add nsw i32 %1, %I %arrayidx3 = getelementptr

On Feb 24, 2012, at 9:53 AM, David A. Greene wrote: > Dan Gohman <gohman at apple.com> writes: > >>> These enhancements are critical for us because of the way our frontends >>> work (less than ideal but we have to deal with it), due to some language >>> quirks (casting in C, odd Fortran constructs, etc.) and because users >>> sometimes stretch the

Hi, > Is there a document describing the guts of SCEV anywhere? If you're looking for theoretical background of SCEV (chains of recurrences algebra), you may take a look at this article: http://citeseer.ist.psu.edu/vanengelen00symbolic.html I'm not aware of any LLVM-specific document describing SCEV. > I have a simple question. When looking at a linear SCEVAddRecExpr > with a

Here is original C code: void topup(int a[], unsigned long i) { for (; i < 16; i++) { a[i] = 1; } } Here is the IR before the pass where I expect SCEV to return trip-count value ; Function Attrs: nofree norecurse nounwind uwtable writeonly define dso_local void @topup(i32* nocapture %a, i64 %i) local_unnamed_addr #0 { entry: %cmp3 = icmp ult i64 %i, 16 br i1

On 11/02/2012 10:21 AM, Preston Briggs wrote: > > My initial guess is that a conservative fix is quick and small (make > sure the underlying pointers are loop invariant, otherwise give up). A > better approach would be to somehow turn code like the example into > array references that can be analyzed. I'll need to think about this and > do some reading. Hi Preston, I looked

Is there any chance of replacing/extending the GEP instruction? As noted in the GEP FAQ, GEPs don't support variable-length arrays; when the front ends have to support VLAs, they linearize the subscript expressions, throwing away information. The FAQ suggests that folks interested in writing an analysis that understands array indices (I'm thinking of dependence analysis) should be

Hi, I'm trying to get the following loop to vectorize (simple reduction): unsigned int sum2(unsigned int *a, int len){ unsigned int s = 0; for (int i = 0; i < len; i += 4) s += *a++; return s; } The loop fails to vectorize because SCEV could not compute the loop exit count. It appears SCEV cannot handle the non-unit increment of the loop counter. Is this a known limitation of

----- Original Message ----- > > 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] =

On 11/02/2012 11:02 AM, Hal Finkel wrote: > ----- Original Message ----- >> From: "Tobias Grosser" <tobias at grosser.es> >> To: "preston briggs" <preston.briggs at gmail.com> >> Cc: "Benjamin Kramer" <benny.kra at gmail.com>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> >> Sent: Friday, November

----- Original Message ----- > From: "Tobias Grosser" <tobias at grosser.es> > To: "preston briggs" <preston.briggs at gmail.com> > Cc: "Benjamin Kramer" <benny.kra at gmail.com>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, November 2, 2012 12:56:53 PM > Subject: Re: [LLVMdev]

Hi! I would appreciate some feedback from someone with experience in SCEV/SE. D39346 tries to fix an issue in LV (PR34965) that exposes a limitation in SCEV/SE. The best solution to the LV issue might not be a fix at SCEV/SE level but we may want to report/address SCEV/SE limitation as well. For the snippet below, LV expects SE to return a SCEVAddRecExpr for %21. However, SE returns ((4 * (zext