similar to: [RFC][SCEV] Behavior of AddRec in CompareSCEVComplexity

Hi, Thanks for the input. In my ptr_test.O1.ll, the two loops should fall into the last case due to loop rotations. And I think we should handle that case. I propose to check the dominance relation between loop predecessor blocks of the two loops if there is no dominance relation between their loop headers just like case three. The only thing I'm not pretty sure is that is there guarantee to

Suppose I have a Master.Rnw file that looks something like this: \documentclass[12pt]{mypaper} \usepackage[margin=1in]{geometry} \usepackage{setspace} \usepackage{url} \usepackage{indentfirst} \usepackage{fancyhdr} \usepackage{Sweave} \pagestyle{fancy} \lhead{sonographic rectal diameter and ADHD} \rhead{ } \usepackage{abbrevs} %\usepackage{natbib} %\usepackage{apacite}

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 am trying to load the rgdal library in Mac OS X 10.4.7 (pismo g3 500 mhz). I already loaded sp and compiled rgdal successfully, such that rgdal shows up in the package manager GUI. But when I try to load rgdal, I get the following error message: Error in dyn.load(x, as.logical(local), as.logical(now)) : unable to load shared library '/Users/rhead/Library/R/library/rgdal/

I''m trying to deploy a rails app with no success. I can execute: ''rake remote_exec ACTION=setup'' but when I try to execute : ''rake deploy'' I got this error: loading configuration c:/ruby/lib/ruby/gems/1.8/gems/switchtower-0.10.0 /lib/switchtower/recipes/standard.rb loading configuration ./config/deploy.rb executing task deploy transaction: start

Hi folks, I''ve been staring at this one for far too long. I''m using Windows SVN client + Capistrano to deploy rails app to my hosted server. I can''t seem to get a single successful deployment. I keep getting this "No such file or directory - svn log -q -rhead http://myhost.com/svn/spclient/trunk " . I run this svn command from the cmd prompt and it

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

Thanks for sharing the known problem. I think to solve the problem properly, we need to fully understand why that assumption about dominance is there and the implications of removing it. It would be good if you could be more specific about your idea of nullptr or SCEV_unknown (eg which function would return those values and when), but returning nullptr from getAddExpr or getSCEVAtScope may be

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:

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

this is from a fresh svn checkout: [stvjc at stvjc1 R-devel]$ ls -tl Makefile -rw-rw-r-- 1 stvjc stvjc 12833 Jun 26 07:24 Makefile [stvjc at stvjc1 R-devel]$ svn up At revision 45988. [stvjc at stvjc1 R-devel]$ bin/R R version 2.8.0 Under development (unstable) (--) Copyright (C) The R Foundation for Statistical Computing ISBN 3-900051-07-0 .. > sessionInfo() R version 2.8.0 Under

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

Forwarding to the dev list, in case others ran into similar issues and/or have input on this topic. Bardia Mahjour ----- Forwarded by Bardia Mahjour/Toronto/IBM on 2020/03/30 02:25 PM ----- From: Bardia Mahjour/Toronto/IBM To: listmail at philipreames.com Cc: "Michael Kruse" <llvm at meinersbur.de> Date: 2020/03/26 11:47 AM Subject: Scalar Evolution Expressions Involving Sibling

Hey LLVMDev, I'm working on a ModulePass that uses ScalarEvolution along with several other analyses. After some debugging, it looks to me like ScalarEvolutionWrapperPass does not handle memory correctly for this case. Here's my current understanding of the problem. ScalarEvolutionWrapperPass maintains a unique_ptr to a ScalarEvolution. Calling getSE() dereferences this pointer.

Hello, I'm finding problems with BackEdgeTaken count calculation in even simple fortran loops with gfortran-4.6 + DragonEgg 3.0. Even for simple double loops like this one: program test2 integer i,j,k dimension k(100,100) do j=1,100 do i=1,100 k(i,j) = i enddo enddo write(*,*) k(1,30) end make the ScalarEvolution

Attached 2012/2/8 Marcello Maggioni <hayarms at gmail.com>: > Mmm, sorry, the patch I posted crashes if ExitBr is null (which it may > be ...) , this one should be ok (and passess all the ScalarEvolution > tests in LLVM): > > diff --git a/lib/Analysis/ScalarEvolution.cpp b/lib/Analysis/ScalarEvolution.cpp > index daf7742..b10fab2 100644 > ---

Well, it wasn't intended as a "real" patch to be included , but more as a "proof of concept" for a solution. Do you think it is a valid solution and I'm correct in my assumption? If so then I'll clean up the patch and attach a testcase for inclusion. Thanks! Marcello 2012/2/9 Nick Lewycky <nlewycky at google.com>: > Your patch should include a testcase,

This is the .ll for that graph (attached). I think I understand what you are saying. This particular testcase returns CNC not because the exit block doesn't have a unique predecessor, but because the unique predecessor (the inner loop block) has a successor that is inside the loop (in this case itself, because it's the inner loop block). That doesn't change, anyway, the assuption that

Hi, I have problems to estimate the loop exit count of a simple loop with the ScalarEvolution class. simple loop: ...... int a = 0; for(int i; i < 10; ++i){ a = a + 1; }; ...... For the loop analyzation I use the ScalarEvolution class with the following initialization: ...... void analysis(Function* func) DominatorTree DT = DominatorTree(); DT.recalculate(*func);

Hi Sanjoy, Thank you for looking into this! Yes, your patch does fix my larger test case too. My algorithm gets double performance improvement with the patch, as the loop now has a smaller instruction set and succeeds to unroll w/o any extra #pragma's. I also ran the LLVM tests against the patch. There are 6 new failures: Analysis/LoopAccessAnalysis/number-of-memchecks.ll