search for: applyupd

...to maintain the DomTree and >> PostDomTree class and deprecate the DefferredDominance class. > > There are a couple of possibilities here. First, we can come up with a new > updater class and gradually replace DefferredDominance and and the basic > incremental update API with it (.applyUpdates()). During this process all > the classes can coexists which should make it easier to make the transition > smooth instead of risking breaking multiple places in LLVM at once. The > other approach would be to modify DefferredDominance and make the transition > happen in place, which...

...class first, need to maintain the DomTree and > PostDomTree class and deprecate the DefferredDominance class. > There are a couple of possibilities here. First, we can come up with a new updater class and gradually replace DefferredDominance and and the basic incremental update API with it (.applyUpdates()). During this process all the classes can coexists which should make it easier to make the transition smooth instead of risking breaking multiple places in LLVM at once. The other approach would be to modify DefferredDominance and make the transition happen in place, which should be also doab...

...to maintain the DomTree and PostDomTree class and deprecate the DeferredDominance class. This approach can save redundant code on calling the update function on both DomTree and PostDomTree. Second, the API should be something looks like DT.update(updateStrategy::lazy,updateKind::delete,A,B) or DT.applyUpdates(updateStrategy::lazy,{{ updateKind::delete,A,B }}). Third, the API can auto flush() when a query happens, which can make the code easier to maintain. Forth, the updater class can hold an optional PostDomTree and make its status synchronize with the corresponding DomTree (can use lazy updates un...

...t; >> PostDomTree class and deprecate the DefferredDominance class. > > > > There are a couple of possibilities here. First, we can come up with a > new > > updater class and gradually replace DefferredDominance and and the basic > > incremental update API with it (.applyUpdates()). During this process all > > the classes can coexists which should make it easier to make the > transition > > smooth instead of risking breaking multiple places in LLVM at once. The > > other approach would be to modify DefferredDominance and make the > transition &g...

...lass and deprecate the DefferredDominance class. >> > >> > There are a couple of possibilities here. First, we can come up with a >> > new >> > updater class and gradually replace DefferredDominance and and the basic >> > incremental update API with it (.applyUpdates()). During this process >> > all >> > the classes can coexists which should make it easier to make the >> > transition >> > smooth instead of risking breaking multiple places in LLVM at once. The >> > other approach would be to modify DefferredDomina...

Hi folks, For the past month I’ve been working on improving the DominatorTree and PostDominatorTree in LLVM. The RFC that explains the motivations and plans can be found here: http://lists.llvm.org/pipermail/llvm-dev/2017-June/114045.html . Here’s a short summary of what changed upstream since posting it: - We switched from the Simple Lengauer-Tarjan algorithm for computing dominators

Hi Chijun, Thanks for your interest in the project. I have gone through most of the LLVM Kaleidoscope tutorial and I have > watched the video of the presentation “Dominator Trees and incremental > updates that transcend time” presented on the 2017 LLVM Developers’ > Meeting. I have also started to understand the algorithm mentioned in > the comments of the code related to the

Hello, I’m an undergraduate student studying CS in the South China University of Technology. I have been using clang compiler and related tools since I started studying C++ and I would like to work on LLVM in this year’s GSoC. I am interested in “Implement a single updater class for Dominators”. [1] I have achieved a bronze medal in the 2017 ACM-ICPC Asia Xian Regional Contest [2] (being a