search for: updatekind

...t; happen in place, which should be also doable. I think that for prototyping > it would be easier to clone DefferedDominance and replace one use of it at a > time with the new updater class. > >> 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 }}). > > Having update strategies as enums sounds very reasonable, but I'd rather we > didn't teach the DT to do it. I think the existing interface (and the header > file) is already pretty l...

...API, the new class first, need 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 DomT...

...nance and make the transition happen in place, which should be also doable. I think that for prototyping it would be easier to clone DefferedDominance and replace one use of it at a time with the new updater class. 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 }}). > Having update strategies as enums sounds very reasonable, but I'd rather we didn't teach the DT to do it. I think the existing interface (and the header file) is already pretty large and it should...

...also doable. I think that for > prototyping > > it would be easier to clone DefferedDominance and replace one use of it > at a > > time with the new updater class. > > > >> 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 }}). > > > > Having update strategies as enums sounds very reasonable, but I'd rather > we > > didn't teach the DT to do it. I think the existing interface (and the > header...

...; > prototyping >> > it would be easier to clone DefferedDominance and replace one use of it >> > at a >> > time with the new updater class. >> > >> >> 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 }}). >> > >> > Having update strategies as enums sounds very reasonable, but I'd rather >> > we >> > didn't teach the DT to do it. I think the existing interf...

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