similar to: InstCombine, graph rewriting, Equality saturation

Thanks for the response. Should I create a small prototype of equality saturation as an LLVM pass so that there can be some concrete discussion on this? I'd love pointers. Thanks, Siddharth On Wed 6 Sep, 2017, 23:35 John Regehr via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Equality saturation is very cool work and Ross Tate mentioned to me that > he'd be happy to chat

I've started hacking up a branch with a rough implementation of equality saturation. This needs me to add objects such as PEGBasicBlock, PEGInstruction, PEGTerminatorInstruction, etc. (PEG stands for "program expression block"). I wish to share most of the infrastructure that exists - I believe this is already done with Machine*. How do I do this for PEGs? I'd also like to get

> I'd love to see a solution where most of the transformations were > specified in TableGen files and: > 1. We, as a result, had an easy way to convert these into a form where > some SMT-solver-based checker could certify correctness. > 2. We, as a result, has an easy way to somehow check soundness, as a > rewrite system, so we'd know it would reach a fixed point

I see. Is there a pre-existing way to do this in LLVM? Cheers, ~Siddharth. On Thu, 17 Aug 2017 at 02:12 Craig Topper <craig.topper at gmail.com> wrote: > ConstantExprs are immutable, they can't be changed once they are created. > And a ConstantExpr can reference other ConstantExprs. So replacing all uses > of a Value in a ConstantExpr would require creating a new immutable

On 11 Sep 2017, at 21:32, Sean Silva via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > As a data point for this, I did a quick walkthrough of the top-level of instcombine, and one thing that stuck out to me is that it tries to sink instructions in certain "easy" scenarios. That doesn't fit a graph rewriting system. The sinking in instcombine is not always a win. We

Whoops, sorry, I meant "value->replaceAllUsesWith". Should I create a new post with an updated title? Thanks Siddharth On Thu 17 Aug, 2017, 01:05 Tim Northover <t.p.northover at gmail.com> wrote: > On 16 August 2017 at 15:39, (IIIT) Siddharth Bhat via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > From what I have observed, using

Just thinking out loud…. I’m really not familiar with the vast majority of what instcombine does, so please excuse me if my naiveté is too obvious. I can’t help but notice all of the uses of ‘and’ in Daniel B’s description of what instcombine is right now: > On Sep 8, 2017, at 11:27 PM, Daniel Berlin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > FWIW, Before getting to

Hello all, >From what I have observed, using `Inst->replaceAllUsesWith` does not replace uses of the `Inst` in `ConstantExpr`s. Is there some way to have a universal replaceAllUsesWith? Thanks, ~Siddharth. -- Sending this from my phone, please excuse any typos! -------------- next part -------------- An HTML attachment was scrubbed... URL:

On 09/11/2017 10:50 AM, Sean Silva via llvm-dev wrote: > > > On Mon, Sep 11, 2017 at 8:14 AM, Daniel Neilson via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > Just thinking out loud…. I’m really not familiar with the vast > majority of what instcombine does, so please excuse me if my > naiveté is too

Saw this mentioned on Lambda, and thought it was worth pointing out (though I'm betting most of you are Lambda readers). Looks like it's a new approach to mapping out optimizations and picking the best ordering/grouping. http://www.cse.ucsd.edu/~rtate/publications/eqsat/ Just watched the video and am settling down to read the paper, and it looks interesting so far. Anyone more

Hello, I'm implementing a custom Haskell-to-LLVM compiler, and in my experimentation, noticed that GHC is much slower than clang certain examples, such as the ackermann function. However, from reading their respective IRs (Cmm for GHC and LLVM for clang), I don't really see much of a difference. Here is a link to the numbers. (n, m) are the parameters to the ackermann function

On 07/13/2017 06:40 PM, Daniel Berlin via llvm-dev wrote: > Ah yes, it can only return one instruction and you need two. > > NewGVN could still handle it if instsimplify was changed to return the > right binary operators because it has infrastructure that can handle > insertion. > (it would need a little work). > > > (At this point, InstCombine seems to have become

I looked around for the status of OrcJIT FFI support. The last e-mail thread I could find was this one: Link <http://lists.llvm.org/pipermail/llvm-dev/2015-February/081679.html> Raw: http://lists.llvm.org/pipermail/llvm-dev/2015-February/081679.html Is OrcJIT now considered stable enough that there can be "official" exposed C APIs? If not, what's the standard approach if I

On Fri, Jun 17, 2011 at 3:08 PM, Evan Cheng <evan.cheng at apple.com> wrote: > Hi all, > > I'm proposing integer saturation intrinsics. > > def int_ssat : Intrinsic<[llvm_anyint_ty], [LLVMMatchType<0>, llvm_i32_ty]>; > def int_usat : Intrinsic<[llvm_anyint_ty], [LLVMMatchType<0>, llvm_i32_ty]>; > > The first operand is the integer value

Hi all, I'm proposing integer saturation intrinsics. def int_ssat : Intrinsic<[llvm_anyint_ty], [LLVMMatchType<0>, llvm_i32_ty]>; def int_usat : Intrinsic<[llvm_anyint_ty], [LLVMMatchType<0>, llvm_i32_ty]>; The first operand is the integer value being saturated, and second is the saturation bit position. For scalar integer types, the semantics are: int_ssat: x <

On Jun 17, 2011, at 3:42 PM, Eli Friedman wrote: > On Fri, Jun 17, 2011 at 3:08 PM, Evan Cheng <evan.cheng at apple.com> wrote: >> Hi all, >> >> I'm proposing integer saturation intrinsics. >> >> def int_ssat : Intrinsic<[llvm_anyint_ty], [LLVMMatchType<0>, llvm_i32_ty]>; >> def int_usat : Intrinsic<[llvm_anyint_ty],

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

Cool! Looks like we do lots of provably unnecessary alignment checks. :) On Tue, Nov 25, 2014 at 9:03 AM, John Regehr <regehr at cs.utah.edu> wrote: > Actually, let me save you some time by pointing out the thing that is > perhaps immediately useful about our recent work, which is the fact that > Souper now supports "optimization profiling". > > If you build an

I hope there's some useful material in here! http://blog.regehr.org/archives/1192 John

We (the folks working on Souper) would appreciate any feedback on these IR-level superoptimizer results: http://blog.regehr.org/extra_files/souper-jul-15.html My impression is that while there's clearly plenty of material in here that doesn't want to get implemented in an opt pass, there are a number of gems hiding in there that are worth implementing. Blog post containing