search for: ppciseldagtodag

...ke: (and (shl GPRC: $rA, (i32 imm:$imm8)),0xFF00) they do not work. Im doing printouts of DAG after legalization (llc -view-legalize-dags) and that complex pattern which I specify seems to be correct. It seems that the problem is with function: SDNode *PPCDAGToDAGISel::Select(SDOperand Op) in PPCISelDAGtoDAG.cpp file with case ISD::ADD when it checks whenever and'ed constant is rotated first. In such case he puts PPC::RLWINM instruction into DAG (return CurDAG- >SelectNodeTo(N, PPC::RLWINM, MVT::i32, Ops, 4);) My question is: can I use patterns to fetch that - if yes, then how (there i...

Dale Johannesen wrote: > I'm not working on it, but I might be able to help find the problem. > What this means is that you're generating code in PIC mode, and an > object that requires a PIC register to reference is being addressed, > and no PIC register was allocated. The allocation was supposed to > happen in PPCDAGtoDAGISel::Select when the reference was processed,

I'm not working on it, but I might be able to help find the problem. What this means is that you're generating code in PIC mode, and an object that requires a PIC register to reference is being addressed, and no PIC register was allocated. The allocation was supposed to happen in PPCDAGtoDAGISel::Select when the reference was processed, and a MovePCtoLR instruction inserted at that

...160bbd0, DW=0x1608fe0, TII=@0x1803ce0) at SelectionDAGISel.\ cpp:856 #16 0x005efe54 in llvm::SelectionDAGISel::runOnFunction (this=0x1608780, Fn=@0x1603720) at SelectionDAGISel.cpp:327 #17 0x002a3aea in (anonymous namespace)::PPCDAGToDAGISel::runOnFunction (this=0x1608780, Fn=@0x1603720) at PPCISelDAGToDAG.cpp:54 #18 0x00874127 in llvm::FPPassManager::runOnFunction (this=0x1606610, F=@0x1603720) at PassManager.cpp:1323 #19 0x0087464c in llvm::FunctionPassManagerImpl::run (this=0x1606410, F=@0x1603720) at PassManager.cpp:1281 #20 0x008747da in llvm::FunctionPassManager::run (this=0xbffff520, F=@...

...0x1803ce0) at SelectionDAGISel.\ > cpp:856 > #16 0x005efe54 in llvm::SelectionDAGISel::runOnFunction > (this=0x1608780, Fn=@0x1603720) at SelectionDAGISel.cpp:327 > #17 0x002a3aea in (anonymous > namespace)::PPCDAGToDAGISel::runOnFunction (this=0x1608780, > Fn=@0x1603720) at PPCISelDAGToDAG.cpp:54 > #18 0x00874127 in llvm::FPPassManager::runOnFunction > (this=0x1606610, F=@0x1603720) at PassManager.cpp:1323 > #19 0x0087464c in llvm::FunctionPassManagerImpl::run > (this=0x1606410, F=@0x1603720) at PassManager.cpp:1281 > #20 0x008747da in llvm::FunctionPassManager::ru...

...) at SelectionDAGISel.\ >> cpp:856 >> #16 0x005efe54 in llvm::SelectionDAGISel::runOnFunction (this=0x1608780, >> Fn=@0x1603720) at SelectionDAGISel.cpp:327 >> #17 0x002a3aea in (anonymous namespace)::PPCDAGToDAGISel::runOnFunction >> (this=0x1608780, Fn=@0x1603720) at PPCISelDAGToDAG.cpp:54 >> #18 0x00874127 in llvm::FPPassManager::runOnFunction (this=0x1606610, >> F=@0x1603720) at PassManager.cpp:1323 >> #19 0x0087464c in llvm::FunctionPassManagerImpl::run (this=0x1606410, >> F=@0x1603720) at PassManager.cpp:1281 >> #20 0x008747da in llvm::Functio...

...> TII=@0x1803ce0) at SelectionDAGISel.\ > cpp:856 > #16 0x005efe54 in llvm::SelectionDAGISel::runOnFunction (this=0x1608780, > Fn=@0x1603720) at SelectionDAGISel.cpp:327 > #17 0x002a3aea in (anonymous namespace)::PPCDAGToDAGISel::runOnFunction > (this=0x1608780, Fn=@0x1603720) at PPCISelDAGToDAG.cpp:54 > #18 0x00874127 in llvm::FPPassManager::runOnFunction (this=0x1606610, > F=@0x1603720) at PassManager.cpp:1323 > #19 0x0087464c in llvm::FunctionPassManagerImpl::run (this=0x1606410, > F=@0x1603720) at PassManager.cpp:1281 > #20 0x008747da in llvm::FunctionPassManager::run (t...

Hi, I have implemented intrinsics which are placeholders for instructions executed elsewhere (e.g. in HW). So i have two types of intrinsics migrate_begin and migrate_end. Now i would like to make these intrinsics known to the PowerPC backend. Since the hardware initialization can not be implemented by one instruction it has to be expanded to a library call or lowered to something the ppc

...ering::getPreIndexedAddressParts, which tells DAGCombine when it can combine the the load and the increment into a singe pre/post-increment load or store. The pre-increment stores are instruction-selected in PPCInstrInfo.td (look for the pre_store patterns). The pre-increment loads are selected in PPCISelDAGToDAG.cpp (TableGen can't yet handle instructions returning multiple outputs), look for the code just after ISD::PRE_INC around line 1060. >From your formula below, it looks like you have a pre-increment load. -Hal > > > On Fri, Oct 24, 2014 at 1:30 AM, Johnny Val < johnnydval at...

...AGISel.\ >> cpp:856 >> #16 0x005efe54 in llvm::SelectionDAGISel::runOnFunction >> (this=0x1608780, Fn=@0x1603720) at SelectionDAGISel.cpp:327 >> #17 0x002a3aea in (anonymous >> namespace)::PPCDAGToDAGISel::runOnFunction (this=0x1608780, >> Fn=@0x1603720) at PPCISelDAGToDAG.cpp:54 >> #18 0x00874127 in llvm::FPPassManager::runOnFunction >> (this=0x1606610, F=@0x1603720) at PassManager.cpp:1323 >> #19 0x0087464c in llvm::FunctionPassManagerImpl::run >> (this=0x1606410, F=@0x1603720) at PassManager.cpp:1281 >> #20 0x008747da in llvm::Fun...

On Fri, 12 Jan 2007, Nicolas Geoffray wrote: > I'm currently implementing a linux/ppc target in llvm. The abis between cool > Darwin/ppc and linux/ppc are different and I'm running into problems > with vararg calls. ok > Before a variadic method is called, an extra instruction must be > executed (which is creqv 6, 6, 6). This instruction is not necessary in >

Hi all, I'm currently implementing a linux/ppc target in llvm. The abis between Darwin/ppc and linux/ppc are different and I'm running into problems with vararg calls. Before a variadic method is called, an extra instruction must be executed (which is creqv 6, 6, 6). This instruction is not necessary in Darwin/ppc. I looked into the PowerPC target implementation and the code generation

...rc/AsmParser/Release+Asserts/SparcAsmParser.o differ: byte 58286, line 535 ./lib/Target/Sparc/Disassembler/Release+Asserts/SparcDisassembler.o ../../recurse2be/build/./lib/Target/Sparc/Disassembler/Release+Asserts/SparcDisassembler.o differ: byte 42480, line 184 ./lib/Target/PowerPC/Release+Asserts/PPCISelDAGToDAG.o ../../recurse2be/build/./lib/Target/PowerPC/Release+Asserts/PPCISelDAGToDAG.o differ: byte 135005, line 376 ./lib/Target/PowerPC/Release+Asserts/PPCRegisterInfo.o ../../recurse2be/build/./lib/Target/PowerPC/Release+Asserts/PPCRegisterInfo.o differ: byte 51221, line 39 ./lib/Target/PowerPC/AsmPars...

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

> 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

LLVMers, The 2.4 pre-release is available for testing: http://llvm.org/prereleases/2.4/ If you have time, I'd appreciate anyone who can help test the release. Please do the following: 1) Download/compile llvm source, and either compile llvm-gcc source or use llvm-gcc binary. 2) Run make check, send me the testrun.log 3) Run "make TEST=nightly report" and send me the

Hi Steve, Thanks for the tip regarding MIOperandInfo, I didn't think of that part of the tablegen description. Sadly, I did actually mean: r1 = *(i0 += m0). So increment i0 by m0. Read memory the memory location "pointed" to by i0. Store in r1. Sadly I am not too familiar with compiler terminology, so I don't know if there is a proper term for such a load. On Thu, Oct 23,