similar to: [GSoC 2018] A single updater class for Dominators in LLVM

Hi Sagar, Thanks for the interest in the project. I left you some comments and feedback in the google doc with your proposal. Let us know if you have any questions. Sincerely, Jakub On Wed, Mar 21, 2018 at 2:37 PM, Sagar Thakur via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > I am a first year M.Tech (computer science) student at IIIT Hyderabad. I > am interested

Hi Vedant, I am a first year M.Tech (computer science) student at IIIT Hyderabad. I am interested in working on two of the LLVM projects. 1. Improve debugging for optimized code. 2. Implement a single updater class for the dominator tree. I have merged both the proposals in a single document because the GSoC portal allows me to upload only one document for applying to LLVM. 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

Hi Chijun, I left you my feedback in the doc (+ some nitpicks). Overall, it looks very solid and shows you understand the problem well and know what to expect. Your proposed timeline is reasonable and I don't see any major things to improve there. Don't hesitate to reach out if you have any questions related to my comments (either here or in the document). Thanks, Kuba On Wed, Mar 21,

Hi Kuba, Thanks for your feedback. I have made some improvements on the proposal according to your feedback and clarify something on the time availability. I left comments on the questions you asked in the doc. Please check it out. Thanks, Chijun 2018-03-22 10:37 GMT+08:00 Jakub (Kuba) Kuderski <kubakuderski at gmail.com>: > Hi Chijun, > > I left you my feedback in the doc (+

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

Hi Kuba, Thanks for your clarification on the project in the previous letter. I have submitted a proposal draft at the GSoC website, the draft has been shared with the LLVM organization. I will appreciate it if you can give me some advice on the proposal. This draft can be viewed by the organization. (If you do not have access, please mail me, and I will give you the link.) I am looking forward

Hi Kuba, Thanks for your advice in your previous letter. During last week, I have read the documents on Doxygen and the source code of the DomTreeBase/DomTree/PostDomTree/DeferredDominance class, I believe now I have a much better understanding on the relationship between these classes and how DeferredDominance class performs lazy updates. I have also learnt the current usage and drawbacks of

Hi Chijun, Great, seems like you did a lot of progress and understand the issues quite well! I have done some early sketch on the API of the new updater class. > From my current understanding, to solve the fragmentation problem of > the API, the new class first, need to maintain the DomTree and > PostDomTree class and deprecate the DefferredDominance class. > There are a couple of

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 Devs, I am Kamlesh Kumar,CS undergraduate at NIT Manipur,India. I have been programming in C/C++ for more than 3 year. I have gone through various LLVM Core libraries and it's tool as well implemented it in my project .I am well aware of core concepts related to LLVM and it's code base, I have read three books available at Safari Online Books 1. LLVM - Essentials 2. LLVM - Cookbook 3.

Btw, here is another interesting paper about post-dominators and control dependence: https://pdfs.semanticscholar.org/cbb2/9a0e4895025bd9df24f9263217df12f1ed1e.pdf I think a great outcome of your internship would be some precise documentation regarding the guarantees the LLVM dominators give -- possibly also considering classic and weak control dependence and the difference between

Hi Tobias, 1) Daniel and Chandler have for a long time been talking about computing > dominance and post-dominance in one shot to reduce the cost of > post-dominance and make it (freely) available everywhere. Is this > covered by your current (or planned) work? I'm not sure what you exactly mean by one shot; I'll ask around tomorrow. I wanted to play a little bit with your

Hi folks, This summer I'm working on improving dominators during my internship at Google. Below is an RFC on switching to dynamic dominators, which you can also read as a Google Doc <https://docs.google.com/document/d/1wPYeWykeO51YDPLYQEg4KNTlDIGIdyF65OTfhSMaNHQ/edit?usp=sharing> if you prefer so. Please let us know what you think. ~Kuba

Hello, I was wondering whether or not some behaviour that I am seeing is expected behaviour and that it has been designed like this, or not. A dominator relation is given by "if A dominates B", then all paths to B go through A. For example, take the CFG below (which is a directed graph (couldn’t make the arrow heads but ok.): A / \ B C \ / D | E We can construct

Hi Jakub, On Tue, Jul 7, 2020 at 6:25 AM Jakub (Kuba) Kuderski <kubakuderski at gmail.com> wrote: > There's a lot of heavily templated code in generic DomTee construction/updater, MemSSA updater, and GraphDiff that has become really hard to modify. For the context, Alina (cc'd) was recently looking into making the domtree code work with 'CFG views'; the basic idea is to

Hi folks, I’m working on adding an API for incremental updates to DominatorTree and I noticed that there isn’t a simple way to quickly build and update CFG (just for testing) -- one has to either build CFG programmatically, or write IR by hand and manually map pointers to basic blocks. The downside is that it tends to be pretty verbose and not easy to update (e.g. adding a new edge often involves

Hi all, This is a request for comment on a series of patches which introduce a new way of writing algorithms that are generic over different types of CFG. What is this? ============= This series of patches introduces a set of classes and templates for: 1. Working on basic blocks and values generically, in particular with the same algorithm implementation on both LLVM IR and MachineIR (in SSA

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

Hello, My proposal for GSoC 2018 on implementing a single updater class for Dominators [1] was accepted. This summer, I’ll work with my mentor Jakub Kuderski on implementing a new uniform API for Dominators and I will try to make incremental updates faster on that basis. Thanks, Chijun Sima [1] https://docs.google.com/document/d/1u16tMTV-OiOTW1mpdk88IFj6lV8Hb7-LijH0MIBl0IU/edit?usp=sharing