similar to: [LLVMdev] SCEV ordering

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 +

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 >

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 {

On Jul 29, 2013, at 4:08 PM, Guo, Xiaoyi <Xiaoyi.Guo at amd.com> wrote: > Hi, > > We have a benchmark where there are 128 MAD computations in a loop. (See the attached IR.) Creating SCEVs for these expressions takes a long time, making the compile time too long. E.g., running opt with the “indvars” pass only takes 45 seconds. > > It seems that the majority of the time is

Hi Andy, Thanks very much for looking into the problem. In this particular test case, it seems most of the time is spent in the sorting, not the grouping. Later, I realized that it seems in this test case most of the expressions to be compared have different length. I tried the following change in compare() when the LHS and RHS's types are the same:

Tobias Grosser wrote: > You create a map from the old_loop to a symbolic expression. What type would > this symbolic expression have? Would it be a SCEVExpr? evaluateAtIteration takes a scev, so apply will take a scev, or a map (loop->scev). You can always build a ScevUnknown from an SSA name and use that in the apply. > At the moment, we calculate at the beginning of each >

I'd like a value, call it Bottom, such that SE->getAddExpr(Bottom, X) => Bottom SE->getMulExpr(Bottom, X,) => Bottom isKnownPredicate(any, Bottom, X) => false etc. I can write code to make NULL work like I want, but it would be simpler if something was already defined. I'm wondering about SCEV::Unknown. The documentation suggests I could perhaps use it for a

On Sun, 7 Oct 2012 18:53:59 -0700 Preston Briggs <preston.briggs at gmail.com> wrote: > I'd like a value, call it Bottom, such that > > SE->getAddExpr(Bottom, X) => Bottom > SE->getMulExpr(Bottom, X,) => Bottom > isKnownPredicate(any, Bottom, X) => false > etc. > > > I can write code to make NULL work like I want, but it would be > simpler

Hi Preston, I was wondering ... "Bottom" is a bit overloaded as far as terms go. Would SCEVNaN be a better name for this beast? Sameer. > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of Sameer Sahasrabuddhe > Sent: Monday, October 08, 2012 9:16 AM > To: preston.briggs at gmail.com > Cc: LLVM

Hi Tobi, I would like to remove the SCEVRewriter code and replace it with a call to SCEVAddRec::apply (see attached a patch that adds just this function). More precisely I want to add another function called apply_map that applies a map (loop -> expr) on a given scev. This is the apply function on a multi-variate polynomial. So here is an overview of how I would like the scev code generator

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. The obvious way to do this in the existing SCEV framework is to add a new SCEV subclass. I started doing that, but then I decided that it would be nice to be able to split multiple-index getelementptrs into separate SCEV objects that

On Fri, Nov 30, 2012, at 08:46 PM, Sebastian Pop wrote: > Hi Tobi, > > I would like to remove the SCEVRewriter code and replace it with a call > to > SCEVAddRec::apply (see attached a patch that adds just this function). > More > precisely I want to add another function called apply_map that applies a > map > (loop -> expr) on a given scev. This is the apply

Hi, I found issues with INDVARS <-> LSR passes interactions after https://reviews.llvm.org/rL346397. There were two main changes in this commit: 1. Previously we were propagating SCEV add expressions even if DefInst of exit value has hard uses inside the loop. After rL346397 we forbid propagation of SCEV add expressions if DefInst of exit value has hard use inside the loop. 2. Previously

Thanks Cristoph, I have that code in my backend, but unless I do the following, the registers are never considered 'live' into the call. / Handle a function call let isCall = 1, Defs = [ R0, R1, R2, R3, R4, R5, R6, R7, R8, R9, R10, R11, R12, R13, R14, R15, R16, R17, R18, R19, R20, R21, R22, R23, R24, R25, R26, R27, R28, R29, R30, R31, R32, R33, R34, R35, R36, R37, R38, R39, R40, R41,

On Fri, 2011-11-11 at 23:55 +0100, Tobias Grosser wrote: > On 11/11/2011 11:36 PM, Hal Finkel wrote: > > On Thu, 2011-11-10 at 23:07 +0100, Tobias Grosser wrote: > >> On 11/08/2011 11:29 PM, Hal Finkel wrote: > >> Talking about this I looked again into ScalarEvolution. > >> > >> To analyze a load, you would do: > >> > >> LoadInst *Load

Hi Micah, > In X86InstrInfo.td for Call Instructions, it mentions that Uses for > argument registers are added manually. Can someone point me to the > location where they are added as the comment doesn't reference a > where or how? the register uses are added by the function X86TargetLowering::LowerCall() during the DAG Lowering phase. This is the relevant code segment: // Add

The Problem? Nowaday, SCEV called "Scalar Evolution" does only evolate instructions that has predictable operand, Constant-Based operand. such as that can evolute as a constant. otherwise we couldn't evolate it as SCEV node, evolated as SCEVUnknown. important thing that we remember is, we do not use SCEV only for Loop Deletion, which that doesn't really needed on nature loops

On 11/12/2011 12:11 AM, Hal Finkel wrote: > On Fri, 2011-11-11 at 23:55 +0100, Tobias Grosser wrote: >> On 11/11/2011 11:36 PM, Hal Finkel wrote: >>> On Thu, 2011-11-10 at 23:07 +0100, Tobias Grosser wrote: >>>> On 11/08/2011 11:29 PM, Hal Finkel wrote: Talking about this I >>>> looked again into ScalarEvolution. >>>> >>>> To

Thanks for fixing this Sanjoy! I do have a few questions/suggestions on the fix if you don't mind. 1) Would this work correctly if the values are call instructions with no operands, like this- %a = foo() %b = bar() 2) From the way this function is set up, it looks like the emphasis is on saving compile time by trading off robustness. Is compile time such a big concern here that we want to

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