similar to: [LLVMdev] new warnings in r58273

On Monday 27 October 2008 17:06, Mike Stump wrote: > llvm/llvm/lib/CodeGen/SelectionDAG/SelectionDAGPrinter.cpp: In member > function ‘void llvm::SelectionDAG::setSubgraphColor(llvm::SDNode*, > const char*)’: > llvm/llvm/lib/CodeGen/SelectionDAG/SelectionDAGPrinter.cpp:372: > warning: comparison with string literal results in unspecified behavior >

On Thursday 02 October 2008 19:22, Dan Gohman wrote: > Another trick is to place an abort() call somewhere in codegen > such that it will be called whenever the construct of interest > is processed, and then run bugpoint. If it works, the result > is a reduced testcase that's still interesting :-). That's a neat trick. I'll see if I can do that. > A feature that

Hi Dan, Thanks for the reply. I got the labels for each outgoing edge (at the source node's 'structure' field) working. Is there a way to find out the outgoing edge number from EdgeIter. (Basically the Node in my graph has a a bunch of outgoing edges, so that I can just index into that collection within the node to get the appropriate edges' attributes). regards, Prakash On Tue,

Hello Prakash, The SelectionDAG viewers (llc -view-isel-dags etc.) support both multiple edges between the same pair of nodes, and labels at least for each incoming edge. See lib/CodeGen/SelectionDAG/SelectionDAGPrinter.cpp for code you might use as an example, though it is a bit tricky. Dan On Sep 15, 2008, at 3:15 PM, Prakash Prabhu wrote: > Hi all, > > I have two questions related

/Volumes/mrs5/net/llvm/llvm/lib/CodeGen/PreAllocSplitting.cpp: In member function ‘bool<unnamed>::PreAllocSplitting::SplitRegLiveInterval (llvm::LiveInterval*)’: /Volumes/mrs5/net/llvm/llvm/lib/CodeGen/PreAllocSplitting.cpp:546: warning: ‘SS’ may be used uninitialized in this function

Hi Prakash, I don't know of an easy way to do this, other than to use random-access iterators so you can compute the distance between the edge and the beginning of the list of edges. Dan On Sep 16, 2008, at 2:58 PM, Prakash Prabhu wrote: > Hi Dan, > > Thanks for the reply. I got the labels for each outgoing edge (at the > source node's 'structure' field) working. Is

On Jul 13, 2009, at 10:02 AM, David Greene wrote: >>> - Tag instructons with source line information (customers really >>> want this). >> >> Right, that would be nice. This should be synthesizable from the >> DebugLoc on the instruction in the asm printer, no need to >> redundantly >> encode it into the comment field. > > Except the DebugLoc

Hi all, I have two questions related to .dot graph output. Basically, I have a graph representing a program dependence graph like structure with (a) multiple edges between the same pair of nodes (b) each edge having a special (different) text/label I implemented a template-specialized version of DotGraphTraits for the my graph structure which given a node, uses a map_iterator (similar to the one

On Monday 13 July 2009 11:40, Chris Lattner wrote: > > I was attempting to reduce the number of files affected, but if you > > want this change I'll go ahead and do it. > > Makes sense, thanks. Please do it as a separate patch from the other > changes though since it will be large and mechanical. Ok, no problem. > > - Tag instructons with source line information

On Monday 13 July 2009 13:13, Chris Lattner wrote: > > We're not going to submit our line number stuff anyway (it's too > > much of a > > hack) but we would like the comment infrastructure to be there. > > DebugLoc is there. The transition isn't complete at the LLVM IR > level, but it is at the MachineInstr level AFAIK. Well, the IR level is pretty

Hello. Quentin, retrieving the LLVM IR instruction from which an SDNode originates is useful during the instruction selection phase. For example, I need to recover the LLVM IR variable which is used to fill an entire vector with the ISD::BUILD_VECTOR target-independent SDNode . From the recovered LLVM IR variable I can walk on the use-def-chains in order to get the most complete

Hello. I would like to access the LLVM IR Instruction from which an SDNode (from SelectionDAG) originates. For this I have modified: - llvm/lib/CodeGen/SelectionDAGISel.cpp, SelectionDAGISel::SelectBasicBlock(), namely I put SDB->clear() at the beginning of the method in order to avoid clearing NodeMap after creating the initial SelectionDAG from LLVM IR, since I want to access

On Oct 2, 2008, at 2:15 PM, David Greene wrote: > On Thursday 02 October 2008 15:37, Dan Gohman wrote: >> >> Also, you can call viewGraph() from within a debugger, to view >> the graph at arbitrary point in the middle of the selection >> process. You can can even put a breakpoint on the Select >> function and view the graph as each individual instruction is

Hello, it looks like I do have infinite loop in llc on linux/armv7 platform somewhere in llvm::SmallVectorImpl. Two backtraces obtained with 10 seconds delay are: 0x0099be14 in llvm::SmallVectorTemplateCommon<llvm::SDNode*>::setEnd (this=0x7ee90b38, P=0x5c06988) at /export/home/karel/vcs/llvm-head/include/llvm/ADT/SmallVector.h:103 103 void setEnd(T *P) { this->EndX = P; }

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 wonder if anyone has any comment on a patch like: diff --git a/lib/CodeGen/SelectionDAG/InstrEmitter.cpp b/lib/CodeGen/SelectionDAG/InstrEmitter.cpp index 65ee3816f84..4780f6f0e59 100644 --- a/lib/CodeGen/SelectionDAG/InstrEmitter.cpp +++ b/lib/CodeGen/SelectionDAG/InstrEmitter.cpp @@ -243,18 +243,21 @@ void InstrEmitter::CreateVirtualRegisters(SDNode *Node,      if (!VRBase &&

Hello, After commit r114523, I start to get crash when compiling with clang (Release+Asserts) for i386: (I know I should fill a bug report instead of posting here, but I don't get much time right now). Trying to compile the following simple code, clang asserts. ---------- round.c -------- #include <math.h> float test() { return llround(1); } -------------------- [MacPro:~/Desktop]

I actually need this feature quite badly in my untyped language compiler: since I support first-class functions, I've made the types of all functions a standard vararg (so I can box them). The implementation crashes when I try to read out the value of gc.result. Hints as to what might be wrong? Signed-off-by: Ramkumar Ramachandra <artagnon at gmail.com> ---

I am running the following llvm-ld command to produce native code: llvm-ld -native -o code.exe code.bc -lm However, I am getting the following assertion failure in llc. The bytecode has been processed with opt, it passes opt bytecode verification. I'm not too familiar with backend code generation. Does anyone have any insight in to what the problem might be or how to go about

Chris: I did float this by the dev list first a couple of weeks ago, didn't receive any comments. It's not entirely gratuitous; the rationale for adding a new node class is threefold: a) Convenience for the backends. Since it benefits multiple backends (PPC and CellSPU), it's a logical addition. I reckon the GPU efforts would also benefit. b) Where else would one encapsulate a