similar to: [LLVMdev] [PATCH] SelectionDAG Debugging

On Wednesday 13 January 2010 16:10, David Greene wrote: > This patch adds a couple of interfaces to dump full or partial > SelectionDAGs. The current code only prints the top-level > SDNode. This patch makes it much easier to understand > CannotYetSelect errors and those sorts of things. In particular, > it helped me track down PR6019. > > Any objections to committing?

On Jan 15, 2010, at 6:57 AM, David Greene wrote: > On Wednesday 13 January 2010 16:10, David Greene wrote: >> This patch adds a couple of interfaces to dump full or partial >> SelectionDAGs. The current code only prints the top-level >> SDNode. This patch makes it much easier to understand >> CannotYetSelect errors and those sorts of things. In particular, >>

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

Since 2.7 is getting close to code freeze, I'd like to see if I can get in our changes to track non-temporal memory operations into trunk. As discussed earlier, I was hoping to do this via metadata. It's pretty clear how to attach the data to Instructions, but after that, I'm not sure what happens. Somehow we have to carry this all the way back into MachineInstrs. What happens to

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

On Feb 23, 2009, at 1:20 PM, Scott Michel wrote: > Chris: > > I did float this by the dev list first a couple of weeks ago, didn't > receive any comments. Ok, I didn't see it, sorry about that. > 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

Hi All I'm having nightmares with FrameIndexes during my backend development :( I have ComplexPatterns defined for my two addressing modes (RR and RI). Most of the time, FrameIndex operands appear to be on load/store nodes, in which case everything works fine as my custom addressing modes matchers work fine. Unfortunately, I now have an add node which has a FrameIndex operand (this results

On Wed, Feb 10, 2010 at 12:02 AM, David Greene <dag at cray.com> wrote: > Since 2.7 is getting close to code freeze, I'd like to see if I can get in our > changes to track non-temporal memory operations into trunk. > > As discussed earlier, I was hoping to do this via metadata.  It's pretty clear > how to attach the data to Instructions, but after that, I'm not

On Feb 23, 2009, at 1:46 PM, Chris Lattner wrote: > In my opinion, the proper direction for shuffles is: > > 1. Back out your patch. > 2. Move the functionality of "is splat" etc to method somewhere, e.g. > on SDNode. > 3. Introduce a new ShuffleVectorSDNode that only has two SDValue > operands (the two input vectors), but that also contains an array of > ints in

On Mon, Feb 23, 2009 at 2:19 PM, Nate Begeman <natebegeman at me.com> wrote: > > On Feb 23, 2009, at 1:46 PM, Chris Lattner wrote: > > In my opinion, the proper direction for shuffles is: >> >> 1. Back out your patch. >> 2. Move the functionality of "is splat" etc to method somewhere, e.g. >> on SDNode. >> 3. Introduce a new

On Jan 15, 2010, at 2:34 PM, David Greene wrote: > On Friday 15 January 2010 16:23, Dan Gohman wrote: >> On Jan 15, 2010, at 1:38 PM, David Greene wrote: >>> On Friday 15 January 2010 15:09, Dan Gohman wrote: >>>>> Sound good? reimplement >>>> >>>> Unlimited-recursion dumping is what the existing dump routines >>>> already do,

On Feb 23, 2009, at 2:15 PM, Scott Michel wrote: > And the first thing the helper method would have to check is if this > SDNode is a BUILD_VECTOR node, right? Right. It's really not much different than what you have now, just moving the point where you check. In your code right now, when you want to call your isConstantSplat method, you first dyn_cast the node to a

Hi everyone, We developed a new backend for our architecture based on LLVM 3.8, I'm sorry about that, I quite understand if my questions do not get any answers because of that. We have some instructions that allow to protect pointers that sit in our small scratch-area. I did not find a way to know, when selecting the machine instructions, if one of the operands of the SDNode is a

On Mon, Feb 23, 2009 at 1:46 PM, Chris Lattner <clattner at apple.com> wrote: > > On Feb 23, 2009, at 1:20 PM, Scott Michel wrote: > > Chris: >> >> I did float this by the dev list first a couple of weeks ago, didn't >> receive any comments. >> > > Ok, I didn't see it, sorry about that. It happens. :-) > a) Convenience for the

I've been investigating a case with the XCore target (which doesn't use FastISel) where the DWARF line number emitted at -O0 results in the xgdb visiting source lines in an unexpected order. I've tracked down the problem to the handling of DebugLocs in the selection DAG, in the getNode method shown bellow. It first tries to find if a similar node already exists in order to use that

On Feb 23, 2009, at 2:49 PM, Scott Michel wrote: > On Mon, Feb 23, 2009 at 2:19 PM, Nate Begeman <natebegeman at me.com> > wrote: > > On Feb 23, 2009, at 1:46 PM, Chris Lattner wrote: > > In my opinion, the proper direction for shuffles is: > > 1. Back out your patch. > 2. Move the functionality of "is splat" etc to method somewhere, e.g. > on

On Friday 26 February 2010 10:34:41 David Greene wrote: > On Friday 26 February 2010 09:55:32 David Greene wrote: > > In the continuing quest to try to track down problems we're seeing in > > SelectionDAG, I added the following assert > > toSelectionDAG::ReplaceAllUsesOfValuesWith: > > Here's a patch to add more of these deleted node asserts. They fire > tons

On Feb 26, 2010, at 2:07 PM, David Greene wrote: > On Friday 26 February 2010 10:34:41 David Greene wrote: >> On Friday 26 February 2010 09:55:32 David Greene wrote: >>> In the continuing quest to try to track down problems we're seeing >>> in >>> SelectionDAG, I added the following assert >>> toSelectionDAG::ReplaceAllUsesOfValuesWith: >>

On Friday 15 January 2010 16:23, Dan Gohman wrote: > On Jan 15, 2010, at 1:38 PM, David Greene wrote: > > On Friday 15 January 2010 15:09, Dan Gohman wrote: > >>> Sound good? reimplement > >> > >> Unlimited-recursion dumping is what the existing dump routines > >> already do, so it's a little odd to have a flag to allow these > > > >

hi, i am building selectionDAG by my own code, but got a assertion fail said "SrcValue is not a pointer?". but since the comment above the SrcValueSDNode said: "SrcValueSDNode - An SDNode that holds an arbitrary LLVM IR Value." why the llvm value of SrcValueSDNode must be with PointerType? is that assertion necessary? thanks a lots. regards --ether