similar to: [LLVMdev] GSoC 2011: Superoptimization for LLVM IR

Hello all, thanks for the feedback! It sounds like you are planning to follow the approach of Joshi, Nelson and > Randall ("Denali: A Goal-directed Superoptimizer") in that you don't intend > to exhaustively enumerate all possible code sequences, and see if they are > the same as the original only better; but instead start from the original > code > sequence and

IMO super optimizer would yield less benefits on LLVM compared to other compilers. If you check the patch of the instcombine pass, you'll find out people keep dragging "correct" optimization out, not because the optimization violates the semantic of LLVM IR, but it will generate wrong code sequences when lowering to machine code. An example: %3 = fcmp %1, %2 %6 = fcmp %4, %5 %7 =

Hi Rafael, don't forget to submit your proposal to GSOC (via the GSOC web-page) - the deadline is today! > > It sounds like you are planning to follow the approach of Joshi, Nelson and > Randall ("Denali: A Goal-directed Superoptimizer") in that you don't intend > to exhaustively enumerate all possible code sequences, and see if they are > the same

A bit of feedback on this proposal: It worries me that you talk about "extending the number of transformations." The point of a superoptimizer is that it has no specific model of transformations. Rather, it is simply looking for cheap code fragments that are equivalent to expensive ones. You have not specified how you will perform equivalence checking between code sequences. The

Here's an idea for a research project that I thought I'd put out there since probably nobody in my group will have time to follow up on it. It would be interesting to take ideas from this superoptimizer for x86: http://theory.stanford.edu/~aiken/publications/papers/asplos06.pdf http://theory.stanford.edu/~sbansal/superoptimizer.html and adapt them to run on LLVM code. It would

One thing that is important to consider is where in the pipeline these kinds of optimizations fit. We normally try to put the IR into a canonical simplified form in the mid-level optimizer. This form is supposed to be whatever is most useful for exposing other optimizations, and for lowering, but only in a generic sense. We do have some optimizations near the end of our pipeline (vectorization,

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

On 07/22/2015 01:28 PM, Sean Silva wrote: > > > On Wed, Jul 22, 2015 at 12:54 PM, Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel at anl.gov>> wrote: > > One thing that is important to consider is where in the pipeline > these kinds of optimizations fit. We normally try to put the IR > into a canonical simplified form in the mid-level optimizer.

On 4/9/07, Domagoj Babic <babic.domagoj at gmail.com> wrote: > > > Traditionally, such analyses have been considered too expensive to be > practical, and were mostly an academic curiosity. The core of the > problem is the lack of adequate automated decision procedures which > could quickly determine whether a set of constraints is satisfiable or > not, and if it is

Hi, On 23/07/15 19:11, Philip Reames wrote: > > > On 07/23/2015 07:24 AM, John Regehr wrote: >>> I guess another way to select interesting transformations could be to look >>> for sequences where the >>> result uses a "subset" of the input instruction sequence. >> >> Yeah, I had been noticing those subsets too. It sounds like it's

Dear LLVMers, This email is intended for those interested in path-sensitive analysis, integer overflow analysis, static analysis, and (perhaps) loop invariant computation. Traditionally, such analyses have been considered too expensive to be practical, and were mostly an academic curiosity. The core of the problem is the lack of adequate automated decision procedures which could quickly

Hi Guys, I checked the open projects on LLVM site, and superoptimizer theme seems to be quite interesting for me. So im going to write the LLVM superoptimizer (http://theory.stanford.edu/~aiken/publications/papers/asplos06.pdf) :) Is this theme still actual? Could you please advise me some usefull articles? -- Best regards, Sergey 2012/5/26 Serg Anohovsky <serg.anohovsky at gmail.com>: >

Hi Zhongxing, On 4/8/07, Zhongxing Xu <xuzhongxing at gmail.com> wrote: > I think the real difficult thing in path sensitive program analysis (or > symbolic execution) is not the lack of decision procedures, but the > translation of arbitrary pointer operations and library function calls in > C/C++ program into the mathematics supported by the automated theorem > prover. >

On 3/23/2011 6:07 AM, Крылов Владислав wrote: > Hi folks, > > I like open technologies, epecially LLVM compiler. I want to implement > a new interface layer in LLVM to plug-in optimizers as a part of GSoC, > and then load the interface with optimizers. LLVM already has a plug-in framework for loading new analysis and optimization passes

Hi folks, I like open technologies, epecially LLVM compiler. I want to implement a new interface layer in LLVM to plug-in optimizers as a part of GSoC, and then load the interface with optimizers. This would improve LLVM application for people who want to use their optimizations in compilers. The first "educative" step is to add Doxygen (for .h files) to the build and integrate it

> example (x+y)-x -> y. Here the right-hand side "y" is a particularly simple > subexpression of the original :) Yeah. We have not found a lot of this kind of thing-- it looks like you and others scooped up a lot of the low-hanging fruit! John

> I guess another way to select interesting transformations could be to look for sequences where the > result uses a "subset" of the input instruction sequence. Yeah, I had been noticing those subsets too. It sounds like it's worth a try doing a run that looks only for those. One nice thing is that if we're just looking for subsets, we will not even give the

On 07/23/2015 07:24 AM, John Regehr wrote: >> I guess another way to select interesting transformations could be to >> look for sequences where the >> result uses a "subset" of the input instruction sequence. > > Yeah, I had been noticing those subsets too. It sounds like it's > worth a try doing a run that looks only for those. > > One nice thing

On Wed, May 27, 2009 at 5:26 PM, Mark Lacey <superoptimizer at gmail.com> wrote: > Hi All, > Hi Mark, > I'm relatively new to LLVM (but not optimizing compilers), and have been > reading docs and browsing code. > Bienvenue! > I noticed in the 2.4 release notes that a sparse propagation framework had > been added based on the SCCP algorithm. I might have a need for

On Thu, 2008-03-27 at 09:51 -0600, John Regehr wrote: > Hey, you need to be careful with this reasoning or else you'll end up > implementing a whole new language, compiler, and OS. > > Oh wait nevermind :). Don't forget prover. :-) shap