Hi Guys, I saw in the API that DominanceFrontier has been deprecated. Is this for real? I have read the computational issues but shouldn't that be left to the users of llvm? My concern is I am writing a Control Dependence module that uses Dominance-Frontier information. Getting rid of Dominance Frontiers will put me in a tight spot. George -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120820/5d8cc525/attachment.html>
Hi George,> I saw in the API that DominanceFrontier has been deprecated. Is this for real? > I have read the computational issues but shouldn't that be left to the users of > llvm? > My concern is I am writing a Control Dependence module that uses > Dominance-Frontier information. > Getting rid of Dominance Frontiers will put me in a tight spot.if the dominancefrontier code is deleted from LLVM you can always add a copy of the last version of the code to your project for your own private use. Ciao, Duncan.
On Aug 20, 2012, at 12:39 PM, Duncan Sands <baldrick at free.fr> wrote:> Hi George, > >> I saw in the API that DominanceFrontier has been deprecated. Is this for real? >> I have read the computational issues but shouldn't that be left to the users of >> llvm? >> My concern is I am writing a Control Dependence module that uses >> Dominance-Frontier information. >> Getting rid of Dominance Frontiers will put me in a tight spot. > > if the dominancefrontier code is deleted from LLVM you can always add a copy of > the last version of the code to your project for your own private use.That's right. It should be easy to maintain. If you search the list archives I'm sure you'll find some motivation and alternatives. My take on it is: checking the dominance frontier on-the-fly is easy, we want to discourage passes from precomputing all frontiers as a global analysis. -Andy
George Baah <georgebaah at gmail.com> writes:> Hi Guys, > > I saw in the API that DominanceFrontier has been deprecated. Is this > for real? > I have read the computational issues but shouldn't that be left to the > users of llvm? > My concern is I am writing a Control Dependence module that uses > Dominance-Frontier information. > Getting rid of Dominance Frontiers will put me in a tight spot. > > GeorgeHi, I had the same issue implementing a pass that build PDGs for an exam two months ago. As an alternative to the (post)-dominance frontier method I used the algorithm described in [1], section 9.5 "Program Dependence Graph" where you can find a method to build the CDG using only the post-dominator tree. Happy hacking, Marco [1] Advanced Compiler Design & Implementation by Steven S. Muchnick
The issue is that when I call the PostDominatorTree pass and I try to get the root of the tree, I get the seg fault. When I compile llvm in release mode everything works fine and dandy. I removed the inline attribute from the functions in PostDominators.h and recompiled llvm in debug mode. Same problem! The problems has to do with the PostDominators.h or PostDominatorTree. I am not even sure any longer. --George On Tue, Aug 21, 2012 at 10:57 AM, Marco Minutoli <mminutoli at gmail.com>wrote:> George Baah <georgebaah at gmail.com> writes: > > > Hi Guys, > > > > I saw in the API that DominanceFrontier has been deprecated. Is this > > for real? > > I have read the computational issues but shouldn't that be left to the > > users of llvm? > > My concern is I am writing a Control Dependence module that uses > > Dominance-Frontier information. > > Getting rid of Dominance Frontiers will put me in a tight spot. > > > > George > > Hi, > > I had the same issue implementing a pass that build PDGs for an exam two > months ago. > > As an alternative to the (post)-dominance frontier method I used the > algorithm described in [1], section 9.5 "Program Dependence Graph" where > you can find a method to build the CDG using only the post-dominator > tree. > > Happy hacking, > Marco > > [1] Advanced Compiler Design & Implementation by Steven S. Muchnick >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120821/68bff73e/attachment.html>