search for: ssaupdator

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

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 form, and also maintain LCSSA form. - Don't bother with LCSSA form input, assume the worst, and use powerful incremental SSA formation utilities built on SSAUpdater to form SSA on demand when needed. (Note,

...s to deal with the ordering of llvm.eh.exception and llvm.eh.selector. > The hacked is contained within the attached patch. it looks like you tried to copy the code for eh.exception. There are two problems with this: (1) the eh.exception code really needs to be rewritten to make use of the new SSAUpdator (then all the mucking around with domtree can go away; it's quite tricky to preserve dominfo when updating the IR, and the whole dom approach is inefficient), and (2) the eh.selector case is much more complicated because selectors carry type infos (and filters) around with them. Sadly, you can...

On Jan 6, 2012, at 5:08 PM, Chris Lattner wrote: >>> >>> It's very like SSA construction, but must make provision >>> testing anti dependences. I had planned to use dominance frontiers to >>> guide placement of phi nodes, as usual. >> >> Ok, in that case, please check out include/llvm/Transforms/Utils/SSAUpdater.h, >> which is the

It sounds like Transforms/Utils/SSAUpdater may be what you are looking for. A good example of how to use it -- one that sounds very similar to what you're doing -- can be found in Transforms/Scalar/LoopRotation.cpp On Wed, Mar 7, 2012 at 2:03 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > I am splitting a one BB loop into two BB. > > Basically, the one loop BB has 3 incoming

Hi Duncan, I hacked together a version of DwarfEHPrepare.cpp which tries to deal with the ordering of llvm.eh.exception and llvm.eh.selector. The hacked is contained within the attached patch. Motivation: I recently created a decent amount of hand coded IR (via the llvm C++ API). In order to help me runtime debug the code, I created automatic constructors which would trace entries into the

Hi, Recently I committed a change (r330175) that passed all my testing, but failed on several bots. Namely, these are the failed ones: http://lab.llvm.org:8011/builders/clang-with-thin-lto-ubuntu/builds/9803 <http://lab.llvm.org:8011/builders/clang-with-thin-lto-ubuntu/builds/9803> http://lab.llvm.org:8011/builders/clang-with-lto-ubuntu/builds/8173

I am splitting a one BB loop into two BB. Basically, the one loop BB has 3 incoming values, one form back edge two from other edges. I want to extract the PHIs from the other two edges out into it's own BB and delete that from the loop, then redirect the backedge to the loopbody (non extracted portion) and create a new PHI coming from the extracted BB and the backedge. I can do this;

On Fri, Dec 23, 2011 at 3:53 PM, Chris Lattner <clattner at apple.com> wrote: > > > On Dec 23, 2011, at 1:35 PM, Preston Briggs wrote: > > > Reading the comments in Analysis/DominanceFrontier.h, I see a note that the structure is deprecated and > > we're not to use it for anything new. > > > > Has it been replaced with something equally useful, or

> On Apr 18, 2018, at 9:11 AM, Roman Lebedev via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Wed, Apr 18, 2018 at 5:45 PM, Michael Zolotukhin via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Hi, >> >> Recently I committed a change (r330175) that passed all my testing, but >> failed on several bots. Namely, these are the failed ones:

On Wed, Apr 18, 2018 at 5:45 PM, Michael Zolotukhin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi, > > Recently I committed a change (r330175) that passed all my testing, but > failed on several bots. Namely, these are the failed ones: > http://lab.llvm.org:8011/builders/clang-with-thin-lto-ubuntu/builds/9803 >

On Dec 31, 2011, at 11:04 AM, Preston Briggs wrote: > Hi Chris, > > I wish we could talk about this at a white board, over a period of > weeks, but email will have to do… That would be nice :) > I don't entirely understand your position about dominance frontiers. > In my experience, they were trivial to compute, requiring very little > time, space, or code. Rereading

Thanks everyone! What are the best tools/techniques to expose such non-deterministic behavior? My hope is to reproduce it on a smaller test (e.g. use some sanitizer and thus make the compiler *fail* when building the test) - Currently these failures only tell me “there is some bug in your code” without any hints where to look for it. Michael > On Apr 18, 2018, at 9:18 PM, Steven Wu

Introduction ============ I'm currently in the middle of what initially looked to be a simple change in GVN but is turning out to have unexpected consequences that are turning out to be quite difficult to resolve, so I thought I'd send out an RFC to make sure that I'm not barking up the wrong tree with how I'm trying to do this. Motivation and current behaviour

> 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 5 November 2014 11:51, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Reid Kleckner" <rnk at google.com> > > To: "Philip Reames" <listmail at philipreames.com> > > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > > Sent: Wednesday, November 5, 2014 12:54:30 PM >

On Fri, Jan 6, 2012 at 8:17 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jan 6, 2012, at 5:08 PM, Chris Lattner wrote: > >>>> >>>> It's very like SSA construction, but must make provision >>>> testing anti dependences.  I had planned to use dominance frontiers to >>>> guide placement of phi nodes, as usual. >>>

Hi Michael, Last year I had a problem with reproducibility that I detected in the generated assembly for the out-of-tree target I was working on that seemed like non-deterministic code generation. There was nothing incorrect in the alternative code being emitted, but it was making me nervous that it was different at all. After some investigation it turned out to be a consequence of

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

Hi, I want to improve the way CGP sinks the incoming values of a PHI node towards memory accesses. Improving it means a lot to some of our key benchmarks, and I believe can benefit many general cases as well. CGP's OptimizeMemoryInst function handles PHI nodes by running AddressingModeMatcher on all incoming values to see whether they reach consensus on the addressing mode. It does a