similar to: Reasoning about results of min and max with a constant

Looks like LVI actually does have cases for max and min; would it be better to allow ValueTracking to use range analysis instead? - CL > On Aug 1, 2016, at 8:44 PM, Philip Reames <listmail at philipreames.com> wrote: > >> On 07/29/2016 07:08 PM, Carlos Liam via llvm-dev wrote: >> Hi all, >> >> Say we have this IR: >> >> %1 = icmp slt i16 %x, 0

On 2016-09-27 02:28, Philip Reames wrote: > On 09/20/2016 12:05 PM, Matti Niemenmaa via llvm-dev wrote: >> I posted some questions related to implementing inference of nsw/nuw >> flags based on known icmp results to Bug 30428 ( >> https://llvm.org/bugs/show_bug.cgi?id=30428 ) and it was recommended >> that I engage a wider audience by coming here. The minimal context is

For those not following along, startingin r301379, Simplify* in InstructionSimplify now can just take a query struct instead of 8000 optional arguments. Nothing is really new since it used the same thing under the covers. I'm slowly converting the old uses away (deletion of the old APIs is a different question). Staring at most of them, i could just directly convert them using braced list

First of all, sorry for the long mail. Inspired by the excellent analysis Rui did for lld, I decided to do the same for llvm. I'm personally very interested in build-time for LTO configuration, with particular attention to the time spent in the optimizer. Rafael did something similar back in March, so this can be considered as an update. This tries to include a more accurate high-level

On Sun, Feb 5, 2017 at 3:41 PM, Nuno Lopes <nunoplopes at sapo.pt> wrote: > Thanks for the answers! The plan makes sense to me. > > Regarding phis, what about diamonds, e.g.: > > > define i32 @f(i32 %x) { > br .., label %bb0, label %bb1 > bb0: > %cmp = icmp sge i32 %x, 0 ; x > 0 > br i1 %cmp, label %bb2, label %bb3 > bb1: > %x2 = add nsw

----- Original Message ----- > From: "Daniel Berlin via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Joerg Sonnenberger" <joerg at britannica.bec.de>, "llvm-dev" > <llvm-dev at lists.llvm.org> > Sent: Thursday, January 14, 2016 10:38:10 AM > Subject: Re: [llvm-dev] High memory use and LVI/Correlated Value > Propagation > On

On Wed, Jan 13, 2016 at 04:28:03PM -0800, Daniel Berlin wrote: > On Wed, Jan 13, 2016 at 4:23 PM, Joerg Sonnenberger via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > On Wed, Jan 13, 2016 at 03:38:24PM -0800, Philip Reames wrote: > > > I don't think that arbitrary limiting the complexity of the search is the > > > right approach. There are

Hi guys, I have an analysis that is able to answer questions like this: given an integer variable, what is the interval of values that this variable can assume during the program's execution? I want to integrate this analysis into LLVM and it seems LVI (Lazy Value Info) is the best place to do this kind of stuff. Can someone give some hints about what I have to do to integrate my analysis

Hello. This question has come up in https://reviews.llvm.org/D70043 There, i'm teaching ConstantRange how no-wrap flags affect the range of `mul` instruction, with end goal of exploiting this in LVI/CVP. There are certain combinations of ranges and no-wrap flags that result in always-overflowing `mul`. For example, `mul nuw nsw i4 [2,0), [4,0)` always overflows:

Hi all, with the current trunk I have two major cases where clang needs more than 2GB memory for compiling programs with -O2. One is related to GVN and MemoryDependenceAnalysis and has a pending patch. The other is related to the Correlated Value Propagation and Lazy Value Information cache. Attached is a heap profile for one of the relevant test cases. Looking at the sources, I don't see any

Hi, Is it intentional that LazyValueInfo.getPredicateAt doesn't solve for the value and only takes assumptions into account? getPredicateAt gets lattice value from cache using getValueAt call: LVILatticeVal LazyValueInfoCache::getValueAt(Value *V, Instruction *CxtI) { ... LVILatticeVal Result; mergeAssumeBlockValueConstantRange(V, Result, CxtI); ... return Result; } Other

On Wed, Jan 13, 2016 at 03:38:24PM -0800, Philip Reames wrote: > I don't think that arbitrary limiting the complexity of the search is the > right approach. There are numerous ways the LVI infrastructure could be > made more memory efficient. Fixing the existing code to be memory efficient > is the right approach. Only once there's no more low hanging fruit should > we

Hi everyone, I posted some questions related to implementing inference of nsw/nuw flags based on known icmp results to Bug 30428 ( https://llvm.org/bugs/show_bug.cgi?id=30428 ) and it was recommended that I engage a wider audience by coming here. The minimal context is the following, please see the bug report for more detail: > 1. If (X s< Y), then both X + 1 and Y - 1 are nsw. > 2.

Hi guys, I am trying to figure out how to use your Lazy Value Info pass, but I am having some questions. First, it seems that the implementation contains infra-structure to deal with range intervals, but the main interface only gives the client information about which values are constants. Is this true? Second, reading the code I see that the ranges are being computed, but I could not tell if

> On Dec 17, 2016, at 1:35 PM, Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > First of all, sorry for the long mail. > Inspired by the excellent analysis Rui did for lld, I decided to do > the same for llvm. > I'm personally very interested in build-time for LTO configuration, > with particular attention to the time spent in the optimizer. >

On 01/13/2016 04:28 PM, Daniel Berlin via llvm-dev wrote: > > > On Wed, Jan 13, 2016 at 4:23 PM, Joerg Sonnenberger via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > On Wed, Jan 13, 2016 at 03:38:24PM -0800, Philip Reames wrote: > > I don't think that arbitrary limiting the complexity of the > search

Dear LLVM community, I would like to contribute to LLVM in the Google Summer of Code project. My proposal is listed below. Please let me know your comments. Adding Range Analysis to LLVM Abstract The objective of this work is patch our implementation of range analysis into LLVM. I have a running implementation of range analysis in LLVM, but it is not currently part of the main distribution. I

On Sun, Feb 5, 2017 at 12:25 PM, Nuno Lopes <nunoplopes at sapo.pt> wrote: > Hi Daniel, > > Many thanks for working on this! > SSI/e-SSA is the only way I'm aware of for doing efficient sparse > analyses, so I'm definitely in favor of adding support for it in LLVM! > > I read the discussion so far and did a cursory review of the patches, and > I have just a

Hi, I am interested in applying to LLVM as part Google Summer of Code 2015. I have been going through LLVM code since about 4 months now, and while going though mailing list discussions I found particular interest in the point raised by Arch Robinson in January about the development of a floating point range check pass in LLVM. I have been in touch with Arch as well as Hal Finkel about this and

On Wed, Mar 23, 2011 at 6:24 PM, John Criswell <criswell at illinois.edu> wrote: > > > On 3/23/11 8:06 AM, Douglas do Couto Teixeira wrote: > > > > the execution of a program. Thus, for each integer variable, a range > > analysis determines its lower and upper limits. A very simple range analysis > > > would, for instance, map each variable to the limits