search for: ssaupdater

...f 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, there are plenty of places where SSAUpdater makes sense, so this isn't really about doing away with it at all.) > > It’s worth noting that LCSSA predates SSAUpdater. If I went back in time and knew what I knew now, I wouldn’t...

...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, there are plenty of places where SSAUpdater makes sense, so this isn't really about doing away with it at all.) In discussions, Andy had expressed a desire to move entirely away from LCSSA and Nick had expressed a desire to do the opposite, so I'...

Hi Garrison, > 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. 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

...gt; >>> 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 preferred API (that doesn't use dom frontiers) to build SSA. > > What approach does it use? I look at the code, but don't really see > an explanation. Sorry, my reading comprehension skills were low, I thought you were asking about MemDep for some reason...

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 t...

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

...clang and lld one more time and run make check - none of these failed on my machine. What else could I try to catch the issue? In case you are interested in details and/or want to try to reproduce it, you’ll need to revert r330180 (and thus reapply r330175). The change is about using a new faster SSAUpdater in Jump Threading, more details are available in the phabricator: https://reviews.llvm.org/D44282 <https://reviews.llvm.org/D44282>. Thanks, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/201...

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

...ck - none of these failed >> on my machine. What else could I try to catch the issue? >> >> In case you are interested in details and/or want to try to reproduce it, >> you’ll need to revert r330180 (and thus reapply r330175). The change is >> about using a new faster SSAUpdater in Jump Threading, more details are >> available in the phabricator: https://reviews.llvm.org/D44282. >> >> Thanks, >> Michael >> >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llv...

...time and run make check - none of these failed > on my machine. What else could I try to catch the issue? > > In case you are interested in details and/or want to try to reproduce it, > you’ll need to revert r330180 (and thus reapply r330175). The change is > about using a new faster SSAUpdater in Jump Threading, more details are > available in the phabricator: https://reviews.llvm.org/D44282. > > Thanks, > Michael > > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.or...

...s? >>> 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 preferred API (that doesn't use dom frontiers) to build SSA. > > What approach does it use? I look at the code, but don't really see > an explanation. Here is some background info: http://blog.llvm.org/2009/12/introduction-to-load-elimination-in-gvn.htm...

...ailed >>> on my machine. What else could I try to catch the issue? >>> >>> In case you are interested in details and/or want to try to reproduce it, >>> you’ll need to revert r330180 (and thus reapply r330175). The change is >>> about using a new faster SSAUpdater in Jump Threading, more details are >>> available in the phabricator: https://reviews.llvm.org/D44282. >>> >>> Thanks, >>> Michael >>> >>> >>> >>> >>> _______________________________________________ >>> L...

...->end edge) * %val2 is available in %a (for the a->b edge) * %val3 is available in %entry (for the entry->b edge) What then happens is: * There are no unavailable values, so full redundancy elimination is done * ConstructSSAForLoadSet is called to do PHI construction * This then uses SSAUpdater * %val2 is set as the value for %a * %val1 is ignored as we already have a value for %a * %val3 is set as the value for %entry * Phi construction is done which completely ignores %val1 The problem here is that SSAUpdater follows the paradigm of one block = one available value, where if a value...

> 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

...as > IntrReadWriteArgMem, but this is not really sufficient to prevent their > removal should the memory be subsequently unused. Plus there are other > places that just delete the lifetime intrinsics, like this in > lib/Transforms/Scalar/SROA.cpp: > > // FIXME: Currently the SSAUpdater infrastructure doesn't reason > about > // lifetime intrinsics and so we strip them (and the bitcasts+GEPs > // leading to them) here. Eventually it should use them to optimize > the > // scalar values produced. > if (IntrinsicInst *II = dyn_cast<Int...

...t; 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 preferred API (that doesn't use dom frontiers) to build SSA. >> >> What approach does it use?  I look at the code, but don't really see >> an explanation. > > Sorry, my reading comprehension skills were low, I thought you were asking abou...

...clang and lld one more time and run make check - none of these failed on my machine. What else could I try to catch the issue? In case you are interested in details and/or want to try to reproduce it, you’ll need to revert r330180 (and thus reapply r330175). The change is about using a new faster SSAUpdater in Jump Threading, more details are available in the phabricator: https://reviews.llvm.org/D44282. Thanks, Michael _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> http://lists.llvm.org/cgi-bin/ma...

...ly do the LCSSA >> etc. transform again if no changes were made, which I suspect is the >> most common case. >> > LCSSA should be linear. Currently it's not because it uses the SSA > updater which computes dominance frontiers, so it might get O(N^3). > The alternative SSAupdater proposed solves this problem using the > novel algorithm from Braun et al. linked in the review > https://reviews.llvm.org/D28934 > It still has the problem that if leaves redundant phis around at the > beginning of the block, e.g. > > %patatino1 = phi [ %tinky, %somebb, %winky, %...

...lse: %q1 = getelementptr inbounds float* %b, i64 4 br label %merge merge: %r1 = phi float* [ %p1, %if.then ], [ %q1, %if.else ] %w1 = load float* %r1 ret void } so we need a solution to attack both issues. While we can solve the second issue by introducing a new base register leveraging SSAUpdater, I am not sure how to fold this complicated logic in MatchOperationAddr which updates one single target addressing mode. One possibility is to extend ExtAddrMode to support multiple base registers, which may complicate a lot of things. While I am thinking about an appropriate solution, I would lik...