similar to: [LLVMdev] viewing CFG in debugging

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

On Aug 13, 2009, at 8:56 AM, Ioannis Nousias wrote: > Hi > > I'm trying to get a graphviz output (DOT) of a code I'm compiling. I > want to see the DFG/CFG of the LLVM assembly, how the operations are > chained together. The documentation mentions something about calling > certain methods from within gdb, but isn't there some option when > invoking the compiler

Hi all, I need to look at the CFG of a loop during debugging. However the containing function is very large, so it is rather difficult to use the CFG of the complete function. I tried using the ViewGraph method, but the compiler kept complaining about undefined symbols related to GraphTraits or DOTGraphTraits. Is there any example that I could look at to find out, what exactly I need to call

On Thu, 2009-08-13 at 17:17 +0100, Ioannis Nousias wrote: > Chris Lattner wrote: > > On Aug 13, 2009, at 8:56 AM, Ioannis Nousias wrote: > > > Hi > > > > I'm trying to get a graphviz output (DOT) of a code I'm compiling. I > > want to see the DFG/CFG of the LLVM assembly, how the operations are > > chained together. The documentation mentions

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

Oh, I tried that, in my previous email, I meant to write: this->DAG.viewGragh() DAG.viewGragh() sorry for the typo in my email... It does not complain about not finding DAG, it complains about not finding viewGragh() in DAG. A. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner Sent: Wednesday, September 26,

Hi, I am trying to use the viewGraph() method of SelectionDAG, of course I installed graghviz, nuked my build directory, reconfigured and rebuilt the project. However, gdb does not consistently recognize SelectionDAG::viewgraph(), some times it finds it and some times it says that llvm::SelectionDAG does not have viewGraph(). It worked for couple of instances when I was in my modules but when for

On Wed, 26 Sep 2007 Alireza.Moshtaghi at microchip.com wrote: > I am trying to use the viewGraph() method of SelectionDAG, of course I > installed graghviz, nuked my build directory, reconfigured and rebuilt > the project. However, gdb does not consistently recognize > SelectionDAG::viewgraph(), some times it finds it and some times it says > that llvm::SelectionDAG does not have

Hi I'm trying to get a graphviz output (DOT) of a code I'm compiling. I want to see the DFG/CFG of the LLVM assembly, how the operations are chained together. The documentation mentions something about calling certain methods from within gdb, but isn't there some option when invoking the compiler (I've seen some -print-cfg and -dot-cfg options mentioned in some source files,

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 Peter, (I'm CC'ing the LLVMdev list as there might be others able to help you) I don't know this assertion, so can't help you with that particular problem. But concerning "more debug info": Do you know the following two links? http://llvm.org/releases/3.0/docs/ProgrammersManual.html#DEBUG You can find some example debug code e.g. in method Select(SDNode *Node) in

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

On Oct 2, 2008, at 9:37 AM, David Greene wrote: > I'm debugging some X86 patterns and I want to understand the debug > dumps from > isel better. > > Here's some example output: > > 0x391bc40: i64,ch = load 0x3922c50, 0x391b8d0, 0x38dc530 > <0x39053e0:0> <sext > i32> alignment=4 srcLineNum= 10 > 0x3922c50: <multiple use> >

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 (+

> Oh, I tried that, in my previous email, I meant to write: > this->DAG.viewGragh() > DAG.viewGragh() > sorry for the typo in my email... > It does not complain about not finding DAG, it complains about not > finding viewGragh() in DAG. Gragh or Graph. Don't you mean viewGraph() ? Aaron

Hi all, http://www.llvm.org/docs/ProgrammersManual.html#BuildRecType suggests us to define recursive types via opaque and refine. Since LLVM has structural types, %rt = type { %rt* } and %rt1 = type { %rt* } should be same structurally. I tested the following code, %rt = type { %rt* } %rt1 = type { %rt* } define i32 @main() nounwind { entry: %0 = alloca %rt ;

On Thursday 02 October 2008 15:37, Dan Gohman wrote: > I highly recommend the viewGraph() output. -view-isel-dags and > -view-sched-dags show the graph before and after selection, > respectively. See the CodeGen docs where I recently added some > text describing all these options. Yeah, I've been using those but they're real hard to understand with big graphs. > Also,

Hi, I'm writing my first hello world Pass with the class name First, but when I tried to load it using opt, I got the following error: /var/soft/llvm-2.2-build/lib/Transforms/Hello$ opt -load ../../../Debug/lib/First.so --help opt: /var/soft/llvm-2.2/lib/VMCore/Pass.cpp:157: void<unnamed>::PassRegistrar::RegisterPass(llvm::PassInfo&): Assertion `Inserted && "Pass