similar to: [LLVMdev] [RFC] LCSSA vs. SSAUpdater ... FIGHT!

On Feb 7, 2014, at 11:29 AM, Chris Lattner <clattner at apple.com> wrote: > > On Feb 1, 2014, at 4:33 AM, Chandler Carruth <chandlerc at gmail.com> wrote: > >> So, there are two primary ideas behind SSA form management in the loop optimizers of LLVM: >> >> - Require LCSSA form input, leverage its (very powerful) guarantees to simplify maintaining SSA

On Wed, Jan 22, 2014 at 12:33 AM, Andrew Trick <atrick at apple.com> wrote: > > There appear to be two chunks of "functionality" provided by loop passes: > > > > 1) A worklist of loops to process. This is very rarely used: > > 1.1) LoopSimplify and LoopUnswitch add loops to the queue. > > I’m making this up without much thought, but we may benefit

On Wed, Jan 22, 2014 at 1:01 AM, Andrew Trick <atrick at apple.com> wrote: > On Jan 22, 2014, at 12:44 AM, Chandler Carruth <chandlerc at gmail.com> > wrote: > > > On Wed, Jan 22, 2014 at 12:33 AM, Andrew Trick <atrick at apple.com> wrote: > >> > There appear to be two chunks of "functionality" provided by loop >> passes: >> >

> I'm not necessarily sympathetic to the idea of adding another canonicalization pass only for this purpose. The problem is that as you said, SimplifyCfg does all sorts of stuff, and I suspect is not the fastest pass in the world. Also, in the case that annoys me, there is an LCSSA pass in the middle, and I suspect it would be a better idea to only do the LCSSA etc. transform again if no

> On Oct 14, 2016, at 9:54 AM, Igor Laevsky <igor at azulsystems.com> wrote: >> >> Hi Michael, > Hi Igor, Hi Michael, > >> >> +CC llvm-dev >> >> My guess is that it would be rather error prone to pinpoint exact places where we start populating new LPPassManager since it’s created lazily via LoopPass::assignPassManager. So we are risking to

Hi Michael, +CC llvm-dev My guess is that it would be rather error prone to pinpoint exact places where we start populating new LPPassManager since it’s created lazily via LoopPass::assignPassManager. So we are risking to miss adding verifiers in some of the LPPassManager’s. One similar idea is to introduce LCSSAVerifier function pass and make LCSSA pass to be dependant on it. That will allow

As came up recently in other threads, loop passes really get in the way. Here are some of the ways: - There is only one Loop analysis pass - IVUsers. It seems unlikely that the loop nest walk is critical to computing this or preserving it. - Almost all of the things we think of as "required" and dependencies are actually *transforms* that canonicalize the form of a loop into particular

Hi Igor, On Oct 17, 2016, at 10:39 AM, Igor Laevsky <igor at azulsystems.com<mailto:igor at azulsystems.com>> wrote: On Oct 14, 2016, at 9:54 AM, Igor Laevsky <igor at azulsystems.com<mailto:igor at azulsystems.com>> wrote: Hi Michael, Hi Igor, Hi Michael, Hi Michael, What I was referring to is that we can write something like this inside LPPassManager iteration: if

Hello. I am trying to create my own LoopVectorize.cpp pass as a separate pass from the LLVM trunk, as described in http://llvm.org/docs/CMake.html#embedding-llvm-in-your-project. Did anybody try something like this? I added close to the end of the .cpp file: /* this line seems to be required - it allows to run this pass as an embedded pass by giving opt -my-loop-vectorize

There's already a LoopSimplifyCFG which is a loop-pass (and thus can iterate with other loop passes) and eliminates trivial branches.  Having a simple pass which just strips unreachable blocks and converts conditional branches to unconditional ones while updating appropriate analyzes (LoopInfo, DomTree, LCSSA, etc..) seems very reasonable.  This could also be a utility function called

On Mon, Jul 25, 2016 at 3:48 PM, Chandler Carruth <chandlerc at google.com> wrote: > On Mon, Jul 25, 2016 at 3:40 PM Finkel, Hal J. via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> *Sent from my Verizon Wireless 4G LTE DROID* >> >> On Jul 25, 2016 6:16 PM, Sean Silva <chisophugis at gmail.com> wrote: >> > >> > >> >

One way you could go is to expose the interface in include/llvm/Transforms/Utils/LoopUtils.h. There's a similar approach in the LCSSA and LoopSimplify passes, both define functions used by other passes (e.g LoopUnroll and LICM). On Fri, Dec 19, 2014 at 10:58 PM, Philip Reames <listmail at philipreames.com> wrote: > I've come across similar use cases recently. In particular,

I've developed a working LLVM back-end (based on LLVM 2.6) for a custom architecture with its own tool chain. This tool chain creates stand-alone programs from a single assembly. We used to use GCC, which supported producing a single machine assembly from multiple source files. I modified Clang to accept the architecture, but discovered that clang-cc (or the Clang Tool subclass inside Clang)

Hello, I am trying to simplify the CFG of a given code and eliminate the conditionals, even though I will obtain codes that are not semantically equivalent. For example, given a simple loop: for(i=0; i<N; i++){    a[i] = i;     if (i%2==0)       a[i] += 12; } I would keep only the loop, without the if statement: for(i=0; i<N; i++){    a[i] = i; } I can eliminate such conditionals on

On Thu, Dec 4, 2008 at 7:08 PM, Chris Lattner <clattner at apple.com> wrote: > > On Dec 4, 2008, at 8:58 AM, Villmow, Micah wrote: > > What optimization pass promotes 32 bit math operations to 64 bit operations > so I can disable it? I have code that works fine with optimizations turned > off but fails with it turned on because of this stage. > > > Do you have a

Hi Mark, It is not clear to me at all that preventing the merging is the right solution. There are a large number of analysis, including alias analysis, and optimizations that use GetUnderlyingObject, and related routines to search back through GEPs. They only do this up to some small finite depth (six, IIRC). So reducing the GEP depth is likely the right solution for InstCombine (which has the

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

On Dec 7, 2007, at 1:43 AM, Wojciech Matyjewicz wrote: > Recently, I was looking into the bug #1227. I wanted to check if > reordering optimization passes could solve it. To start with, I > tried to > reproduce the output of llvm-g++ -O3 using the combination of llvm-g++ > -O0 and opt with the appropriate passes. However, I was unable to. I > use > SVN versions of llvm and

Hi, I've been thinking about how to keep the line number with the llvm transform/Analysis passes. Basically, I agree with Chris's notes ( http://www.nondot.org/sabre/LLVMNotes/DebugInfoImprovements.txt), and I will follow his way to turn on the line number information when optimization enabled. Here is a detailed proposal: 1. Introduction At the time of this writing, LLVM's

I think it would make sense for (1) and (2). I am not sure if (3) is feasible in instcombine. (I am not too familiar with LoopInfo) For the Octasic's Opus platform, I modified shouldMergeGEPs in our fork to: if (GEP.hasAllZeroIndices() && !Src.hasAllZeroIndices() && !Src.hasOneUse()) return false; return Src.hasAllConstantIndices(); // was return false;