similar to: [LLVMdev] DFG of machine functions

I tried debugging it and the issue seems to be in the implementation of MachineInstrIterator.h and the way it interacts with GraphWriter.h functions. I found this by replacing the ( template <> struct GraphTraits<MCDFGraph<MachineFunction*> >) with a similar MCDFGraph based template of CFG similar to the one in MachineFunction.h (similarly replacing the DOTGraphTraits with the

Edwin, thanks, it starts making sense inline comments... Török Edwin wrote: > On 2009-09-06 19:57, Ioannis Nousias wrote: > >> Edwin, >> >> thank you for your effort, but I'm not sure I understand. >> Are you describing a graph traversal problem? Is the data model stored >> in a predecessor/successor fashion, which requires you to 'walk' the

On 2009-09-06 19:57, Ioannis Nousias wrote: > Edwin, > > thank you for your effort, but I'm not sure I understand. > Are you describing a graph traversal problem? Is the data model stored > in a predecessor/successor fashion, which requires you to 'walk' the > graph in order to visit all nodes? (and what happens when you have > disjointed DFGs?). Sorry for the

I've tried to write a DFGPrinter based on the CFGPrinter, as you suggested, but encountered problems. The GraphWriter expects GraphTraits<GraphType>::nodes_begin()/nodes_end(). The way this is implemented in CFG.h, a function is a graph of basic blocks. A GraphTraits<Function*> inherits from GraphTraits<BasicBlock*>, and implements those nodes_begin()/nodes_end()

On 2009-09-06 17:30, Ioannis Nousias wrote: > I've tried to write a DFGPrinter based on the CFGPrinter, as you > suggested, but encountered problems. > > The GraphWriter expects > GraphTraits<GraphType>::nodes_begin()/nodes_end(). The way this is > implemented in CFG.h, a function is a graph of basic blocks. A > GraphTraits<Function*> inherits from

Hi Ioannis, On Thu, 2009-08-13 at 19:31 +0100, Ioannis Nousias wrote: > Thanks Tobi for the tip. > > however I also need the Data-Flow-Graph of each basic block/functions. > As I said, I need a view of how the instructions 'link' to each other > (via registers or memory aliasing or whatnot) I believe that there is not yet a DOT printer for this kind of information.

Edwin, thank you for your effort, but I'm not sure I understand. Are you describing a graph traversal problem? Is the data model stored in a predecessor/successor fashion, which requires you to 'walk' the graph in order to visit all nodes? (and what happens when you have disjointed DFGs?). inline comments follow... Török Edwin wrote: > On 2009-09-06 17:30, Ioannis Nousias

Some time ago we reported a compile-time performance regression in the LiveIntervals analysis pass (see http://llvm.org/bugs/show_bug.cgi?id=18580). We detected it at first after migrating from LLVM 3.1 to 3.3, but the problem persists also in 3.5. This regression is especially critical when compiling long functions. In one of our benchmarks compile time goes from 200s (in 3.1) up to 1500s (in

Chris Lattner wrote: > It's more of an algorithm than a datastructure. Where else in the > codebase would it be useful to use? If only in one place, it is > probably reasonable to put it near the code that uses it. > > -Chris > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu

I can use llc to compile my IR module to amdgcn with some non-zero output. However, if try to write the output (assembly or object) to a string (via buffer_ostream) the resulting string has always zero length. Here the code changes I do: Original llc:       if (Target->addPassesToEmitFile(PM, *OS,                                       DwoOut ? &DwoOut->os() : nullptr,

Hello, I posted an earlier version of this patch some months ago and realized I've still been sitting on it. The earlier version of this patch was rejected for adding a cycle detection function to SCCIterator.h. This function is now removed. This patch makes the following changes: 1. Allow SCCIterator to work with GraphT types that are constant. 2. Allow SCCIterator to work with

It was brought to my attention that dumping a registry hive causes a lot of time spent in disk I/O activity because iconv_open() and iconv_close() are called for every key. Every iconv_open() call causes /usr/lib/.../gconv/$ENCODING.so to be opened and mapped. The iconv_t handles are now cached in the hive_h struct; they are opened on-demand and re-used. On my ~10 year old Lenovo T60, I have

+ MLIR dev mailing list since that’s where the OrcJit I’m using is. Thanks for all the details, Lang! What you described is exactly what I’m looking for! Please, MLIR dev, let me know if this debug feature and the solution that Lang describes below is interesting for MLIR. I’ll dig more into the details then but it doesn’t seem too complicated. Thanks, Diego From: Lang Hames [mailto:lhames at

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, I am trying to create a table with information from Shapiro Wilk's test of normality. However, it fails due to lack of sample size, it says, but the way I see it, this is not a problem. (See the table of sample sizes (almost) at the bottom). Applying a different function using a similar ftable call is not a problem (See the bottom table). This is R 2.1.0 on Linux (Gentoo). /Fredrik

--- lib/hivex-internal.h | 8 +++++--- lib/utf16.c | 11 +++++++---- 2 files changed, 12 insertions(+), 7 deletions(-) diff --git a/lib/hivex-internal.h b/lib/hivex-internal.h index 4135f58..64fd49a 100644 --- a/lib/hivex-internal.h +++ b/lib/hivex-internal.h @@ -268,11 +268,13 @@ extern size_t * _hivex_return_offset_list (offset_list *list); extern void _hivex_print_offset_list

I've been doing some experiments with the Boost Graph Library (BGL) and interfacing to llvm's GraphWriter system. I'm using GBL for some custom work and needed a way to hook BGL's write_graphviz into GraphWriter to use the existing display infrastructure. To do this I added a HAVE_BOOST configure item and #ifdef'd the Boost support code in GraphWriter. Is this useful to

Issue: GraphWriter includes <ostream>, which my gcc2 apparently thinks is <ostream.h>. Fix: Make a new <Support/ostream> that handles this discrepancy, ala <Support/hash_set>. -- Casey Carter Casey at Carter.net ccarter at uiuc.edu AIM: cartec69 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch URL:

Hi. I'd like to know where LLVM installs the GraphWriter.h file on a standard install. I'd like to know this to avoid any possibility of overwriting it with software that I am developing. Please CC me as I'm off list. Thanks! Paul Blackburn

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