similar to: Way to know if an Operand of a SelectionDAG is a pointer

You cannot detect that by simply looking at the DAG. The way such things are usually done is that you invent your own SDNode that represents the property that you want to examine later. In your case it could be something like YourTargetISD::SMALL_SCRATCH_POINTER, which would take one value and return one value. This node would not cause any code to be generated for it, it would only serve as

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

Hello Ether, I think it is referring to the Value class (captial V) whose documentation is found at http://llvm.org/doxygen/classllvm_1_1Value.html . It has to be a pointer because the Value class is a parent class to many many child classes. --Sam ----- Original Message ---- > From: ether zhhb <etherzhhb at gmail.com> > To: LLVM Developers Mailing List <llvmdev at

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

Thanks Anton and Krzysztof! Here is the dump using the -debug flag. At this point I am not making much sense of this, would it be too much to ask if one of you could walk me through one of these lines? One thing that I didn't point out is that I never defined any separate floating point registers, not sure if this will pose any issue? Thanks again for your time! Jeff jeff at

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

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

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

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

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? -Dave -------------- next part -------------- A non-text attachment

On Mon, Feb 23, 2009 at 4:03 PM, Nate Begeman <natebegeman at me.com> wrote: > > It's basically as Chris said; there will be a ShuffleVectorSDNode, and > appropriate helper functions, node profile, and DAGCombiner support. > Fine. For vector shuffles. But again, what about vector constants, e.g., v4i32 <0, 1, 2, 3, 4>? BuildVectorSDNode is still a reasonable subclass

On Friday 26 February 2010 19:09:01 Dan Gohman wrote: > I've now looked at your latest patch. In summary, it does expose a > subtle problem. I haven't seen anything that here would lead to > observable misbehavior yet though. Well, I'm definitely observing misbehavior. I know it has something to do with local changes here but I haven't isolated it yet. >

On Feb 23, 2009, at 6:13 PM, Scott Michel wrote: > On Mon, Feb 23, 2009 at 4:03 PM, Nate Begeman <natebegeman at me.com> > wrote: > > It's basically as Chris said; there will be a ShuffleVectorSDNode, > and appropriate helper functions, node profile, and DAGCombiner > support. > > Fine. For vector shuffles. But again, what about vector constants, >

Hi, all I am studying the ARM backend on SelectionDAG, I have some following questions: 1. Each operator of SDNode in SelectionDAG is required to be defined by SDNode<ISD::XXX,XXX,XXX> in .td file, right? But several operators are not defined in .td file, why? (e.g., ISD::BR_CC, ISD::CopyToReg, ISD::AssertSext) 2. The MVT::glue value is used to ensure two nodes are scheduled

Hi, for DAG-to-DAG instruction selection I’ve implemented a pattern, which creates from one SDNode two instructions, something like: def: Pat<(NEW_SDNODE REG:$r1), (INST_OUT (INST_IN), REG:$r1)>; where INST_IN doesn't accepts any inputs and INST_OUT accepts two inputs - one returned by INST_IN and REG;$r1. Is there any possibility to ‘Glue’ two instruction created