similar to: InstSimplify and computeKnownBits

There's some interest in my "auto-simplifier", which is nice :), so let me explain a bit about it. On 19/01/11 19:35, Sandeep Patel wrote: > You've mentioned your auto-simplifier a few times now and curiosity is > getting the better of me. Can you explain it a bit more? On 20/01/11 00:32, Nuno Lopes wrote: > Just out of curiosity, what's this auto-simplifier?

I've always found the name ComputeMaskedBits a bit unintuitive, and since r154011 it's even worse because there is no masking going on whatsoever: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120402/140280.html Is there any appetite for a global rename to ComputeKnownBits? Or any other better names? Thanks, Jay.

On 13 May 2014 21:27, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > On 13 May 2014 14:33, Jay Foad <jay.foad at gmail.com> wrote: >> I've always found the name ComputeMaskedBits a bit unintuitive, and >> since r154011 it's even worse because there is no masking going on >> whatsoever: >> >>

SelectionDAG's computeKnownBits has no case for ConstantFP, e.g. Known.ones = cast <ConstantFPSDNode>(Op)->getValueAFP ().bitcastToAPInt (); I can't easily override this in target specific code. Can anyone see an issue with submitting the patch to upstream? Suggestions for an in tree target that could trigger this would be very welcome. Cheers -------------- next part

[adding llvm-dev for wider audience] On Fri, May 19, 2017 at 12:28 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Fri, May 19, 2017 at 11:00 AM, Davide Italiano <davide at freebsd.org> > wrote: > >> On Fri, May 19, 2017 at 10:00 AM, Sanjay Patel <spatel at rotateright.com> >> wrote: >> > Is "VRP" (value range

Hello everyone, I'm starting a new thread, as a follow-up to several older ones, on invariants in LLVM. Fundamentally, invariants are conditions that the optimizer is allowed to assume will be valid during the execution of the program. Many other compilers support a concept like this, MSVC's __assume, for example. GCC has a builtin called __builtin_assume_aligned which also neatly falls

While looking at optimizations where Souper exploits known bits, I realized that it would be easy to teach Souper to compute known bits. Comparing its results against computeKnownBits() from r246393, it looks like there are some easy (and some not-easy) opportunities for improvement, please see a few examples below. The expressions come from compiling LLVM itself. Happily, this exercise

> To (hopefully) make it easier to answer this question, I've posted my (work-in-progress) patch which adds a known-bits cache to InstCombine. > I rebased it yesterday, so it should be fairly easy to apply: https://reviews.llvm.org/D31239 - Seeing what this does to the performance of the > benchmarks mentioned in this thread (among others) would certainly be interesting. Thanks! I

Hi, I think we should remove the LoopInstSimplify pass, as it has no test coverage and no users (afaik). If you are using the pass, or think that it should stay in tree for some other reason, please let me know. Here's the patch: https://reviews.llvm.org/D44053 <https://reviews.llvm.org/D44053> vedant -------------- next part -------------- An HTML attachment was scrubbed... URL:

That's very good. We're clearly further from head of dev than I realised! Thanks for the link. On 19 Jan 2018 18:53, "Friedman, Eli" <efriedma at codeaurora.org> wrote: On 1/19/2018 4:01 AM, Jon Chesterfield via llvm-dev wrote: > SelectionDAG's computeKnownBits has no case for ConstantFP, e.g. > Known.ones = cast <ConstantFPSDNode>(Op)->getValueAFP

Thanks for sharing this background information :). If you've got the time, I think it'd be great to check this bulleted list into docs/. I see that we don't have a Canonicalizations.rst or a LoopOptimizations.rst -- your notes look like a good starting point. Given that the pass seems to be doing the right thing from a design perspective, should it stay in tree? Since it's been

Duncan, GVN already does this. See lines 1669-1689. --Owen On Feb 7, 2011, at 4:50 AM, Duncan Sands wrote: > Hi all, I wrote a little pass (attached) which does the following: if it sees a > conditional branch instruction then it replaces all occurrences of the condition > in the true block with "true" and in the false block with "false". Well, OK, it > is a

We're not actively using this, but from a design perspective I'm wondering if we should be using this or something like it.  At the moment, our various loop optimization assume mostly canonical input.  Some of the passes have been taught to deal with limited amounts of non-canonical-ism, but there's a strong code simplicity argument in favor of only handling canonical input and

On the subject of undefined behavior and known bits, as I'm sure some of you are aware, code in ValueTracking.cpp is exploiting poison value rules to get a bit of extra precision in the known bits. These rules fire on examples like the ones below. Do we have a set of rules that clients of known bits need to follow to avoid unsoundness? I remember Nuno and/or David Majnemer saying

The code is simple enough that I'd vote to delete and reintroduce later if needed.  :) Philip On 03/05/2018 01:23 PM, Vedant Kumar wrote: > Thanks for sharing this background information :). If you've got the > time, I think it'd be great to check this bulleted list into docs/. I > see that we don't have a Canonicalizations.rst or a > LoopOptimizations.rst --

This is fundamentally different than the problems we’re trying to handle with the constrained FP intrinsics. The constrained FP intrinsics were necessary because LLVM IR otherwise assumes that FP instructions do not have side effects. In the case of integer divide-by-zero, the optimizer generally recognizes this as a possibility and avoids introducing it (through speculation, for instance). But if

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

While trying to find a solution for this bug http://llvm.org/bugs/show_bug.cgi?id=11235 , I came to the conclusion that the following things can happen while optimizing: - after gvn, I get new constants which are inserted into br and add/sum/..., so there should be at least one more jump-threading and/or instsimplify - after instsimplify, I get new constants which are inserted into br, so there

On Fri, Jun 29, 2012 at 3:10 PM, Renato Golin <rengolin at systemcall.org> wrote: > Hi all, > > It's been a long time, and I'm probably going to kill myself, but I > want to try it anyway. > > Bug 10368 [1] tells me that ConstantExpr shouldn't automatically fold, > and that this is source of many problems (most notably with traps) and > code duplication.

On Wed, Dec 12, 2012 at 01:59:55PM -0800, Dan Gohman wrote: > The bug here isn't in clang's use of noalias or in BasicAliasAnalysis' > implementation of noalias; it's in the code that's optimizing the > icmp. Let's come back to this. The attached patch decouples InstSimplify from the alias analysis and provides the conservative logic for when pointers are not