similar to: Is there any real downside to constructing the new SimplifyQuery once

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

On Fri, Mar 3, 2017 at 12:39 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: On 3/3/2017 11:51 AM, Daniel Berlin via llvm-dev wrote: So i have a testcase (see PR31792, and cond_br2.llin GVN) that current GVN can simplify because it replaces instructions as it goes. It's an example of a larger issue that pops up quite a lot I would appreciate thoughts on what to do about it it

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.

While building test-suite with the new PM, I ran into problems with AssertingVH being triggered which is obvious in retrospect: https://llvm.org/bugs/show_bug.cgi?id=28400 Both cases I ran into revolve around LVI which holds AssertingVH. Essentially, what happens is this: 1. LVI holds an AssertingVH pointing at a BasicBlock 2. Some other pass ends up deleting that BB (e.g. SimplifyCFG) 3. BOOM

On Sun, Apr 5, 2020 at 6:34 PM Stefanos Baziotis < stefanos.baziotis at gmail.com> wrote: > Hi Craig, > > > Adding a nuw to the add -8 is incorrect. > Yeah, I didn't mean to say it was correct. It was just an observation that > with nuw the optimization was happened and I asked if someone thought it > was somehow connected. > > > From the perspective of the

So i have a testcase (see PR31792, and cond_br2.llin GVN) that current GVN can simplify because it replaces instructions as it goes. It's an example of a larger issue that pops up quite a lot I would appreciate thoughts on what to do about it it amounts to something like this (but again, it happens a lot): live = gep thing, 0 live2 = gep thing, 1 branch i1 provablytrue,, mergeblock, otherbb

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

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

The current gvn equality propagation is not powerful enough to get this because it doesn't try to infer values in predicates based on other predicates, so it never realizes a>b -> a !=b in a useful way. It otherwise would get this On Thu, Jun 30, 2016, 7:41 PM Sean Silva <chisophugis at gmail.com> wrote: > On Thu, Jun 30, 2016 at 6:45 PM, Daniel Berlin via llvm-dev <

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

On Thu, Jun 30, 2016 at 6:45 PM, Daniel Berlin via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Thu, Jun 30, 2016 at 6:09 PM, Carlos Liam via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi all, >> >> Consider this C code: >> >> #include <stdbool.h> >> >> bool func(int n1, int n2, bool b) { >>

On Mon, Jul 11, 2016 at 7:51 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi Sean, > > Sean Silva wrote: > > While building test-suite with the new PM, I ran into problems with > > AssertingVH being triggered which is obvious in retrospect: > > https://llvm.org/bugs/show_bug.cgi?id=28400 > > > > Both cases I ran into revolve around LVI

I notice that GetUnderlyingObject has a few checks, but alloca isn't one of them. Then it fall backs to SimplifyInstruction which doesn't know about alloca so falls back to just trying to constant fold it. This seems a little silly since I assume alloca can't be constant folded. Should we just detect this early in GetUnderlyingObject and stop? ~Craig -------------- next part

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

Yep. Makes sense to me. There's nothing to simplify or constant-fold about an alloca. -Hal On 04/12/2017 04:23 PM, Craig Topper wrote: > Ping > > ~Craig > > On Fri, Apr 7, 2017 at 1:25 PM, Craig Topper <craig.topper at gmail.com > <mailto:craig.topper at gmail.com>> wrote: > > I notice that GetUnderlyingObject has a few checks, but alloca >

New patches with review feedback incorporated: * Changed single letter flags to short abbreviations ('S' ==> 'nsz') * Indentation fixes * Comments don't state function names -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fast-math-flags-added-to-FPMathOperator.patch Type: application/octet-stream Size: 4937 bytes Desc: not

----- 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, I am working on some changes to LazyValueInfo and I wanted to see how it was used in existing passes. Currently I can see that Jump Threading and Correlated Value Propagation are the 2 passes that use LazyValueInfo. However on the LLVM docs page of passes (http://llvm.org/docs/Passes.html <http://llvm.org/docs/Passes.html>), Correlated Value Propagation is not mentioned as a pass. Does

PropagateEquality in gvn.cpp However, if you are going to do it, remember the goal is to make the code simpler and easier, not just pile on to the current mess to catch more cases :) On Mon, Jul 4, 2016, 7:51 AM Carlos Liam <carlos at aarzee.me> wrote: > Where would I look to change the equality propagation? > > > - CL > > On Jun 30, 2016, at 11:45 PM, Daniel Berlin