search for: truevalue

Hello Jochen- Your expectation is incorrect, I'm afraid. Typically this would be expanded to something like this: … %cmp = … br i1 %cmp, label %ternary.true, label %ternary.false ternary.true: %truevalue = … br label %ternary.end ternary.false: %falsevalue = … br label %ternary.end ternary.end: %value = phi %type [%truevalue, %ternary.true], [%falsevalue, %ternary.false] This may then be optimised to a select by later passes, if it's considered to be profitable to do so. The reaso...

...I->get(Opc)).addReg(MI->getOperand(2).getReg()) .addReg(Mips::ZERO).addMBB(sinkMBB); // copy0MBB: // %FalseValue = ... // # fallthrough to sinkMBB BB = copy0MBB; // Update machine-CFG edges BB->addSuccessor(sinkMBB); // sinkMBB: // %Result = phi [ %TrueValue, thisMBB ], [ %FalseValue, copy0MBB ] // ... BB = sinkMBB; if (isFPCmp) BuildMI(*BB, BB->begin(), dl, TII->get(Mips::PHI), MI->getOperand(0).getReg()) .addReg(MI->getOperand(2).getReg()).addMBB(thisMBB) .addReg(MI->getOperand(1).getReg()).ad...

...->addSuccessor(copy0MBB); - BB->addSuccessor(sinkMBB); - - // copy0MBB: - // %FalseValue = ... - // # fallthrough to sinkMBB - BB = copy0MBB; - - // Update machine-CFG edges - BB->addSuccessor(sinkMBB); - - // sinkMBB: - // %Result = phi [ %FalseValue, copy0MBB ], [ %TrueValue, thisMBB ] - // ... - BB = sinkMBB; - BuildMI(BB, TII->get(PPC::PHI), MI->getOperand(0).getReg()) - .addReg(MI->getOperand(3).getReg()).addMBB(copy0MBB) - .addReg(MI->getOperand(2).getReg()).addMBB(thisMBB); + if (MI->getOpcode() == PPC::SELECT_CC_I4 || + MI->get...

...er type to be expanded, I inserted some code to explicitly check if MVT::f64 is being expanded. This worked for most of the cases, but not for all. In particular I cannot solve the SELECT_CC on f64 expansion. It generates a target specific SELECT_CC node that correctly contains pairs of i32 for the TrueValue and FalseValue. But when the value of this operation is used later, then expander tries to expand the result of it. And it cannot do it, since it seems to have a problem with EXTRACT_ELEMENT applied to SELECT_CC mentioned above. The problem is probably that it cannot extract the corresponding halve...

PPCTargetLowering::EmitInstrWithCustomInserter has a reference to the current MachineFunction for other purposes. Can you use MachineFunction::getRegInfo instead? Dan On Jul 8, 2008, at 1:56 PM, Gary Benson wrote: > Would it be acceptable to change MachineInstr::getRegInfo from private > to public so I can use it from > PPCTargetLowering::EmitInstrWithCustomInserter? > >

...->addSuccessor(copy0MBB); - BB->addSuccessor(sinkMBB); - - // copy0MBB: - // %FalseValue = ... - // # fallthrough to sinkMBB - BB = copy0MBB; - - // Update machine-CFG edges - BB->addSuccessor(sinkMBB); - - // sinkMBB: - // %Result = phi [ %FalseValue, copy0MBB ], [ %TrueValue, thisMBB ] - // ... - BB = sinkMBB; - BuildMI(BB, TII->get(PPC::PHI), MI->getOperand(0).getReg()) - .addReg(MI->getOperand(3).getReg()).addMBB(copy0MBB) - .addReg(MI->getOperand(2).getReg()).addMBB(thisMBB); + if (MI->getOpcode() == PPC::SELECT_CC_I4 || + MI->get...

Hi Gary, This does not patch cleanly for me (PPCISelLowering.cpp). Can you prepare a updated patch? Thanks, Evan On Jul 10, 2008, at 11:45 AM, Gary Benson wrote: > Cool, that worked. New patch attached... > > Cheers, > Gary > > Evan Cheng wrote: >> Just cast both values to const TargetRegisterClass*. >> >> Evan >> >> On Jul 10, 2008, at 7:36

Just cast both values to const TargetRegisterClass*. Evan On Jul 10, 2008, at 7:36 AM, Gary Benson wrote: > Evan Cheng wrote: >> How about? >> >> const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass : >> &PPC:G8RCRegClass; >> unsigned TmpReg = RegInfo.createVirtualRegister(RC); > > I tried something like that yesterday: > > const

Evan Cheng wrote: > How about? > > const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass : > &PPC:G8RCRegClass; > unsigned TmpReg = RegInfo.createVirtualRegister(RC); I tried something like that yesterday: const TargetRegisterClass *RC = is64bit ? &PPC::GPRCRegClass : &PPC::G8RCRegClass; but I kept getting this error no matter how I arranged it:

You need to insert new basic blocks and update CFG to accomplish this. There is a hackish way to do this right now. Add a pseudo instruction to represent this operation and mark it usesCustomDAGSchedInserter. This means the intrinsic is mapped to a single (pseudo) node. But it is then expanded into instructions that can span multiple basic blocks. See

...->addSuccessor(copy0MBB); - BB->addSuccessor(sinkMBB); - - // copy0MBB: - // %FalseValue = ... - // # fallthrough to sinkMBB - BB = copy0MBB; - - // Update machine-CFG edges - BB->addSuccessor(sinkMBB); - - // sinkMBB: - // %Result = phi [ %FalseValue, copy0MBB ], [ %TrueValue, thisMBB ] - // ... - BB = sinkMBB; - BuildMI(BB, TII->get(PPC::PHI), MI->getOperand(0).getReg()) - .addReg(MI->getOperand(3).getReg()).addMBB(copy0MBB) - .addReg(MI->getOperand(2).getReg()).addMBB(thisMBB); + if (MI->getOpcode() == PPC::SELECT_CC_I4 || + MI->get...

Would it be acceptable to change MachineInstr::getRegInfo from private to public so I can use it from PPCTargetLowering::EmitInstrWithCustomInserter? Cheers, Gary Evan Cheng wrote: > Look for createVirtualRegister. These are examples in > PPCISelLowering.cpp. > > Evan > On Jul 8, 2008, at 8:24 AM, Gary Benson wrote: > > > Hi Evan, > > > > Evan Cheng wrote:

This is the old MIPS I code that sort of does what I need to do. This seems really involved to do such a simple thing. Maybe there are now helper classes for this or some better example I can look at. I suppose I can mimick this if people say this just the correct way to do this in LLVM. static MachineBasicBlock* ExpandCondMov(MachineInstr *MI, MachineBasicBlock *BB,

...> inserted some code to explicitly check if MVT::f64 is being expanded. > This worked for most of the cases, but not for all. In particular I > cannot solve the SELECT_CC on f64 expansion. It generates a target > specific SELECT_CC node that correctly contains pairs of i32 for the > TrueValue and FalseValue. But when the value of this operation is used > later, then expander tries to expand the result of it. And it cannot do > it, since it seems to have a problem with EXTRACT_ELEMENT applied to > SELECT_CC mentioned above. The problem is probably that it cannot > extract the...

Chris Lattner wrote: > On Jun 27, 2008, at 8:27 AM, Gary Benson wrote: > > def CMP_UNRESw : Pseudo<(outs), (ins GPRC:$rA, GPRC:$rB, i32imm: > > $label), > > "cmpw $rA, $rB\n\tbne- La${label}_exit", > > [(PPCcmp_unres GPRC:$rA, GPRC:$rB, imm: > > $label)]>; > > } > > > > ...and

...->addSuccessor(copy0MBB); - BB->addSuccessor(sinkMBB); - - // copy0MBB: - // %FalseValue = ... - // # fallthrough to sinkMBB - BB = copy0MBB; - - // Update machine-CFG edges - BB->addSuccessor(sinkMBB); - - // sinkMBB: - // %Result = phi [ %FalseValue, copy0MBB ], [ %TrueValue, thisMBB ] - // ... - BB = sinkMBB; - BuildMI(BB, TII->get(PPC::PHI), MI->getOperand(0).getReg()) - .addReg(MI->getOperand(3).getReg()).addMBB(copy0MBB) - .addReg(MI->getOperand(2).getReg()).addMBB(thisMBB); + if (MI->getOpcode() == PPC::SELECT_CC_I4 || + MI->get...

On Fri, 17 Nov 2006, Roman Levenstein wrote: > I still have some questions about FP emulation for my embedded target. > To recap a bit: > My target only has integer registers and no hardware support for FP. FP > is supported only via emulation. Only f64 is supported. All FP > operations should be implemented to use i32 registers. ok > allocation. But anyway, I have an almost

After discussions last night, I'm leaning towards going legit with all my pseudo expansions in Mips 16. Some I think I can clearly do by just putting in the proper side effects of implicit registers (T8 the condition code register as used by mips 16). But I'm still left with some pseudos that have jmp .+4 type instructions in them. The original Mips port was to Mips I and Mips I,

Hi, I still have some questions about FP emulation for my embedded target. To recap a bit: My target only has integer registers and no hardware support for FP. FP is supported only via emulation. Only f64 is supported. All FP operations should be implemented to use i32 registers. Based on the fruitful discussions on this list I was already able to implement mapping of the FP operations to