search for: ppcdagtodagisel

...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 time. Somebody can > probably figure it out by stepping through that. I'm an LLVM user, not and LLVM dev. I've read the above and and get the basic idea, but I can't find PPCDAGtoDAGISel::...

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 time. Somebody can probably figure it out by stepping through that. On Oct 27, 2010, at 10:16 AMPDT, D. Johnson wrote: > Erik de Castro Lopo <mle+cl <at> mega-nerd.com> writes: > >>...

Hi, I have two questions about the above method of the SelectionDAGISel class. 1. The overrides in PPCDAGToDAGISel and in I64DAGToDAGISel are identical (except for PPCISD::FIRST_NUMBER vs. IA64ISD::FIRST_NUMBER). Maybe, this means that it would be better if SelectionDAGISel had default implementation? That would remove this code duplication. If desired, SelectionDAGISel can have both implementation and be pur...

...hat use a ISD::SETCC node with a ISD::SETLT parameter. On PPC, ISD::SELECT is expanded, and here both of these SELECT nodes are expanded into ISD::SELECT_CC nodes with a ISD::SETLT node used by both. These SELECT_CC nodes are not directly instruction selected, instead they should be handled by the PPCDAGToDAGISel::Select function. This function always transforms SELECT_CC nodes into PPC-specific nodes that can be instruction selected; in doing so the ISD::SETLT (and all similar comparison operator nodes) should be dropped (they are not used in the node passed to CurDAG->SelectNodeTo). During instruction...

...code: Using an undefined physical register *** - function: check - basic block: for.end50 0x2bef428 (BB#38) - instruction: BCTR8 %CTR8<imp-use>, %RM<imp-use> - operand 0: %CTR8<imp-use> LLVM ERROR: Found 1 machine code errors. This comes from the following four statements in PPCDAGToDAGISel::Select; what's wrong here? SDValue Chain = N->getOperand(0); SDValue Target = N->getOperand(1); unsigned Opc = PPC::MTCTR8; unsigned Reg = PPC::BCTR8; Chain = SDValue(CurDAG->getMachineNode(Opc, dl, MVT::Other, Target, Chain), 0); return CurD...

On Wed, 1 Mar 2006, Vladimir Prus wrote: > I have two questions about the above method of the SelectionDAGISel class. > > 1. The overrides in PPCDAGToDAGISel and in I64DAGToDAGISel are identical > (except for PPCISD::FIRST_NUMBER vs. IA64ISD::FIRST_NUMBER). > Maybe, this means that it would be better if SelectionDAGISel had default > implementation? That would remove this code duplication. Yup, that would be great. > 2. What are possible...

...I try to fetch something more complex like: (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...

...lBasicBlocks (this=0x1608780, Fn=@0x1603720, MF=@0x160d520, MMI=0x160bbd0, 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...

...> Successors according to CFG: BB#23 BB#15 BB#7 BB#8 BB#9 BB#10 BB#11 BB#25 BB#12 BB#16 BB#18 BB#13 BB#17 How could CRT8 be marked implicitly-defined and also dead in the same instruction when it is clearly used in the next instruction? The code that inserts these instructions is in SDNode *PPCDAGToDAGISel::Select(SDNode *N) and reads: case ISD::BRIND: { // FIXME: Should custom lower this. SDValue Chain = N->getOperand(0); SDValue Target = N->getOperand(1); unsigned Opc = Target.getValueType() == MVT::i32 ? PPC::MTCTR : PPC::MTCTR8; unsigned Reg = Target.getValueType() ==...

..., Fn=@0x1603720, MF=@0x160d520, MMI=0x160bbd0, > 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...

...603720, MF=@0x160d520, MMI=0x160bbd0, 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=@...

...s=0x1608780, Fn=@0x1603720, MF=@0x160d520, MMI=0x160bbd0, 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 PassMa...

Erik de Castro Lopo <mle+cl <at> mega-nerd.com> writes: > > Hi all, > > I'm compiling current SVN HEAD on Linux/x86. The tests are failing > on PowerPC due to the following assertion failure : > > JITTests: PPCCodeEmitter.cpp:152: unsigned int<unnamed>::PPCCodeEmitter:: > getMachineOpValue(const llvm::MachineInstr&, const

Chris Lattner wrote: > On Wed, 1 Mar 2006, Vladimir Prus wrote: >> I have two questions about the above method of the SelectionDAGISel >> class. >> >> 1. The overrides in PPCDAGToDAGISel and in I64DAGToDAGISel are identical >> (except for PPCISD::FIRST_NUMBER vs. IA64ISD::FIRST_NUMBER). >> Maybe, this means that it would be better if SelectionDAGISel had default >> implementation? That would remove this code duplication. > > Yup, that would be great. >...

...60d520, MMI=0x160bbd0, >> 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=0x160641...

Hi all, I'm compiling current SVN HEAD on Linux/x86. The tests are failing on PowerPC due to the following assertion failure : JITTests: PPCCodeEmitter.cpp:152: unsigned int<unnamed>::PPCCodeEmitter:: getMachineOpValue(const llvm::MachineInstr&, const llvm::MachineOperand&) const: Assertion `MovePCtoLROffset && "MovePCtoLR not seen yet?"'

On Dec 5, 2011, at 12:56 PM, Hal Finkel wrote: > RegScavenger is complaining about use of an undefined register, CTR8, in > the BCTR8 instruction, in the following instance (this is from the PPC > backend): > > BB#38: derived from LLVM BB %for.end50 > Predecessors according to CFG: BB#36 > %X3<def> = LD 0, <fi#27>; mem:LD8[FixedStack27] >

On Thu, Jul 12, 2012 at 01:22:39PM +0200, Fabian Scheler wrote: > Hi Micah, > > > We have a very similar setup with the AMDIL backend(some operations support 64bit some don't). > > > > What we do is we enable MVT::i64, set legal to all operands that are legal and then set everything else to expand. > > thanks for your hint. Unfortunately, I didn't find any

...ement Expand for > ISD::Constant or Custom lower it in your backend. thank you for that information. This exactly is what I feared. Well I did some more mostly unguided hacking and these are the opportunities I found/was pointed to: 1. Implement custom lowering in the backend (cf. eg. SDNode *PPCDAGToDAGISel::Select(SDNode *N)) It is not a big issue to split the constant in the 32 higher and lower bits and to load these fragments separately. However, I don't know how to ensure that these fragments are put into the proper subregisters of the register pair forming the 64bit register. For the PPC-bac...

Hi Micah, > We have a very similar setup with the AMDIL backend(some operations support 64bit some don't). > > What we do is we enable MVT::i64, set legal to all operands that are legal and then set everything else to expand. thanks for your hint. Unfortunately, I didn't find any time to work on my problem in the meantime as I was busy preparing lectures. However, the summer