similar to: Accessing the associated LLVM IR Instruction for an SDNode used in instruction selection (back end)

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

Seems llvm cannot pass metadata to MachineInstr, or setting operand description in class Instruction and pass to class MachineInstr. Is it a good idea to extend llvm kernel structure to having this feature? Jonathan > On Nov 27, 2017, at 9:01 PM, Jatin Bhateja <jatin.bhateja at gmail.com> wrote: > > SelectionDAGBuilder contained within SelectionDAGISel has a map (NodeMap) b/w

I'm trying to write a tablegen pattern to that matches a sequence of SDNodes and emits again an SDNode and another instruction. The pattern I've written looks like the folowing: def : Pat<(foo (bar GPR:$rs1), simm12:$imm1), (bar (BAZ GPR:$rs1, simm12:$imm1))>; foo and bar are SDNodes, BAZ is an instruction. In particular, bar is defined as follows: def bar :

TLDR: Heads up for out of tree backends - you're going to need to update your *DAGToDAGISel::Select method to unconditionally replace nodes directly instead of returning the desired replacement. So I'm working on fixing the undefined behaviour I described in llvm.org/PR26808. As part of this, we need to stop looking into deleted SDNodes to check if they were, in fact, deleted. A big place

Update: All in tree backends now implement `void Select`. I'll be removing the SelectImpl path on Monday. Justin Bogner <mail at justinbogner.com> writes: > TLDR: Heads up for out of tree backends - you're going to need to update > your *DAGToDAGISel::Select method to unconditionally replace nodes > directly instead of returning the desired replacement. > > So I'm

Can you put something in the release notes when this happens? Thanks, Hans On Sat, May 21, 2016 at 10:57 AM, Justin Bogner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Update: All in tree backends now implement `void Select`. I'll be > removing the SelectImpl path on Monday. > > Justin Bogner <mail at justinbogner.com> writes: >> TLDR: Heads up for out of

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

Hi Ryan, On Fri, 2007-04-06 at 13:34 -0500, Ryan M. Lefever wrote: > 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

Is a PR a bug report on the bugzilla database? I am also running bugpoint to see if that yields anything. Reid Spencer wrote: > Hi Ryan, > > On Fri, 2007-04-06 at 13:34 -0500, Ryan M. Lefever wrote: > >>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

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

> 3. Introduce a new ShuffleVectorSDNode that only has two SDValue > operands (the two input vectors), but that also contains an array of > ints in the node (not as operands). ... > The important part of #3 is that we really want an array of ints > (using -1 for undef) for the shuffle mask, not "operands". This > eliminates the nastiness we have now were we

On Fri, 2007-04-06 at 14:27 -0500, Ryan M. Lefever wrote: > Is a PR a bug report on the bugzilla database? Yes, so named because of the URL translation. I.e. http://llvm.org/PR123 takes you to bugzilla bug 123. PR == Problem Report. > I am also running > bugpoint to see if that yields anything. Okay, good. That might turn up something useful. If you suspect its a bug, please file

Duncan: I'm still stymied how this whole thread ended up about shuffle vector nodes, when the original problem was my build vector patch. I'm still working on backing the build vector patch out (it isn't clean with all of the intervening commits and I have pressing management tasks which command my attention.) -scooter On Tue, Feb 24, 2009 at 12:28 AM, Duncan Sands <baldrick at

I believe this patch has broken a PPC app that I am tracking. Here is a reduced test case. Reproduce with llc -mattr=+Altivec -mcpu=g5. The backtrace looks like this: #0 0x9333ae42 in __kill () #1 0x9333ae34 in kill$UNIX2003 () #2 0x933ad23a in raise () #3 0x933b9679 in abort () #4 0x933ae3db in __assert_rtn () #5 0x0008bd8f in llvm::MVT::getVectorElementType (this=0xbfffdda4) at

I am trying to understand the SelectionDAG construction from LLVM IR. I have gone through the doc "The LLVM Target-Independent Code Generator" on LLVM site. This gives a great initial overview. However I am unable to catch the actual control flow for the llvm->selectionDag conversion. The flags "-view-sched-dags".. described in the doc doesn't seem to work. ( "llc

Hi all, considering following .ll file ; ModuleID = 'vect3x.ll' target triple = "armv7-none-linux-gnueabi" define arm_aapcscc void @test_hi_char8(i8* %.T0351, <8 x i8>* nocapture %srcA, <4 x i8>* nocapture %dst) noinline { L.entry: %0 = tail call arm_aapcscc i32 (...)* @get_global_id(i8* %.T0351, i32 0) %1 = bitcast <8 x i8>* %srcA to <4 x i8>*

Things are still broken. Unfortunately llvm test suite does not contain enough vector code to fully test this. Can you revert the patch first? Evan On Feb 24, 2009, at 7:14 PM, Scott Michel wrote: > Evan: > > I did not encounter this back trace before I committed the newest > BuildVectorSDNode patch, which removed all class instance members > and passes results back via

I was running into a problem with compiling llvm with gcc 4.4 on fedora 11 with --enable-optimized. I was seeing this warning dozens of times: /net/hakodate/scratch/llvm/llvm/include/llvm/CodeGen/ValueTypes.h: In member function ‘llvm::SDNode*<unnamed>::SPUDAGToDAGISel::Select(llvm::SDValue)’: /net/hakodate/scratch/llvm/llvm/include/llvm/CodeGen/ValueTypes.h:362: warning: comparison always

Evan: I work on reverting it, although, when I tried yesterday, it wasn't particularly clean (lots of rejected patches, presumably due to intervening commits.) Are you still getting the backtrace or is this just a case of incorrectly generated code? -scooter On Wed, Feb 25, 2009 at 10:09 AM, Evan Cheng <echeng at apple.com> wrote: > Things are still broken. Unfortunately llvm

Evan: I did not encounter this back trace before I committed the newest BuildVectorSDNode patch, which removed all class instance members and passes results back via reference parameters. -scooter On Tue, Feb 24, 2009 at 11:39 AM, Evan Cheng <evan.cheng at apple.com> wrote: > I believe this patch has broken a PPC app that I am tracking. Here is a > reduced test case. Reproduce