similar to: Evaluate SCEV on "typically expected value"

Hi, As far as I understand, AssumptionTracker is just a compile-time optimization to avoid having to iterate over instructions to find a relevant @llvm.assume. In case of @llvm.expect, one can just look up the definition, which would be the @llvm.expect. Some time ago there was a patch that replaced AssumptionTracker but got reverted. I see an issue with @llvm.expect's design. It should not

Hi, We come across a ScalarEvolution (SE) problem the other day. It seems to be a fundamental design problem. I don't think I have a clean and cheap fix to this problem. I talked with Andy in the phone yesterday, he told me it is a known fundamental problem. But I don't see any discussion on this problem on the list, so I post the problem here, soliciting your insightful comment.

Hi Sanjoy, Thanks for the reply! Would it be possible for you to implement this? You know the codebase better than I do. Thanks, Pankaj -----Original Message----- From: Sanjoy Das [mailto:sanjoy at playingwithpointers.com] Sent: Tuesday, March 13, 2018 1:34 PM To: Chawla, Pankaj <pankaj.chawla at intel.com> Cc: Maxim Kazantsev <max.kazantsev at azul.com>; Serguei Katkov

Hi Sanjoy, So what is the verdict on this issue? Thanks, Pankaj -----Original Message----- From: Chawla, Pankaj Sent: Monday, February 26, 2018 11:12 AM To: Sanjoy Das <sanjoy at playingwithpointers.com> Cc: Maxim Kazantsev <max.kazantsev at azul.com>; Serguei Katkov <serguei.katkov at azul.com>; llvm-dev at lists.llvm.org Subject: RE: [SCEV] Inconsistent SCEV formation for

In short: Shall analysis of a SCEV expression be allowed even though part of the IR that was analyzed to build the SCEV expression has been removed? In more detail with background: About a month ago I landed https://reviews.llvm.org/D87494 where SCEV is used to do additional debug-info salvaging in LSR. The idea was to compute (and store) a SCEV of what llvm.dbg.value intrinsics inside the loop

Hi Pankaj, On Tue, Mar 13, 2018 at 1:55 PM, Chawla, Pankaj <pankaj.chawla at intel.com> wrote: > Thanks for the reply! > Would it be possible for you to implement this? I don't have cycles for this right now, but if you file a bug I can give this a shot when I have time later. Even in the best case this will have to at least wait until end of April because I'm leaving for a

Hi, I was looking at some bugs to play with, and I started with http://llvm.org/bugs/show_bug.cgi?id=18606 As I commented there, a loop is unrolled and exhibit this pattern: %mul.1 = mul i32 %mul, %mul %mul.2 = mul i32 %mul.1, %mul.1 .... With an unroll factor of 32, the last multiply has 2^32 terms in its SCEV expression. (I mean I expect it would have those terms if I was patient

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 Sanjoy, SCEV is behaving inconsistently when forming SCEV for this zext instruction in the attached test case- %conv5 = zext i32 %dec to i64 If we request a SCEV for the instruction, it returns- (zext i32 {{-1,+,1}<nw><%for.body>,+,-1}<nw><%for.body7> to i64) This can be seen by invoking- $ opt -analyze -scalar-evolution inconsistent-scev-zext.ll But when computing

On Nov 13, 2013, at 3:39 AM, Renato Golin <renato.golin at linaro.org> wrote: > 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

Hi, +CC Max, Serguei This looks like a textbook case of why caching is hard. We first call getZeroExtendExpr on %dec, and this call does end up returning an add rec. However, in the process of simplifying the zext, it also calls into isLoopBackedgeGuardedByCond which in turn calls getZeroExtendExpr(%dec) again. However, this second (recursive) time, we don't simplify the zext and cache a

Hi Sanjoy, Thanks for investigating the issue! I am more interested in getting the underlying problem fixed rather than making this particular test case work. I think I have more test cases where this problem crops up. I would any day prefer consistent results over compile time savings which can lead to inconsistencies. These inconsistencies require significant developer time to analyze and fix

Hi Pankaj, On Sun, Feb 11, 2018 at 2:32 PM, Chawla, Pankaj <pankaj.chawla at intel.com> wrote: > Thanks for investigating the issue! > > I am more interested in getting the underlying problem fixed rather than making this particular test case work. I think I have more test cases where this problem crops up. I would any day prefer consistent results over compile time savings which

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

Thank you very much for your reply. Do you mean calculate the hash based on element SCEV pointers? But according to the comments before GroupByComplexity(): /// Note that we go take special precautions to ensure that we get deterministic /// results from this routine. In other words, we don't want the results of /// this to depend on where the addresses of various SCEV objects happened to

On Fri, 20 Apr 2007, Dan Gohman wrote: > The SCEV framework sorts operands of commutative SCEVs by their > getSCEVType() value, and then does an ad-hoc sort to group repeated > operands, but it does not do a full sort. In some test cases I'm > looking at right now, this causes it to miss opportunities to reuse > SCEV objects, as in cases like this: > > ( %i + %r54 +

Hi, So SCEV cannot simplify that expression to -1 because of overflow issues (take e.g. src=0x7FFF..). If you compile with 64 bits integers, then the sexts disappear and so SCEV can do the simplification. Depending on what you want to do, you may want to either do not extend src and dst to 64 bits or add a NSW flag to the computations. That will hopefully make SCEV push the sext outside and

This sounds fine to me (and sorry for the delay!). -- Sanjoy On Mon, Mar 12, 2018 at 1:09 PM, Chawla, Pankaj <pankaj.chawla at intel.com> wrote: > Hi Sanjoy, > > So what is the verdict on this issue? > > Thanks, > Pankaj > > > -----Original Message----- > From: Chawla, Pankaj > Sent: Monday, February 26, 2018 11:12 AM > To: Sanjoy Das <sanjoy at

On Fri, Apr 20, 2007 at 03:16:03PM -0700, Chris Lattner wrote: > > The obvious solution would be to sort the values. Many SCEV types could > > be ordered in reasonable ways, though for SCEVUnknown it would require > > an ordering for Value objects, and I don't really want this to get > > complicated. I'm considering just using getValueID() as a primary sort >

On Sat, Aug 27, 2016 at 7:07 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Wei Mi via llvm-dev" <llvm-dev at lists.llvm.org> >> To: "Daniel Berlin" <dberlin at dberlin.org> >> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "David Li" <davidxl at google.com> >> Sent: