search for: falsevalue

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 reason for this is that C requires that only the value which is...

...t the right instruction according to the type of the operands compared if (isFPCmp) BuildMI(BB, dl, TII->get(Opc)).addMBB(sinkMBB); else BuildMI(BB, dl, TII->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,...

...sors of the current - // block to the new block which will contain the Phi node for the select. - sinkMBB->transferSuccessors(BB); - // Next, add the true and fallthrough blocks as its successors. - BB->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->getOpera...

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

...sors of the current - // block to the new block which will contain the Phi node for the select. - sinkMBB->transferSuccessors(BB); - // Next, add the true and fallthrough blocks as its successors. - BB->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->getOpera...

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

...sors of the current - // block to the new block which will contain the Phi node for the select. - sinkMBB->transferSuccessors(BB); - // Next, add the true and fallthrough blocks as its successors. - BB->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->getOpera...

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,

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

...sors of the current - // block to the new block which will contain the Phi node for the select. - sinkMBB->transferSuccessors(BB); - // Next, add the true and fallthrough blocks as its successors. - BB->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->getOpera...

...we build J*_ri instruction. > + assert (isInt<32>(imm32)); > BuildMI(BB, DL, TII.get(NewCC)) > .addReg(LHS) > - .addImm(MI.getOperand(2).getImm()) > + .addImm(imm32) > .addMBB(Copy1MBB); > + } > > // Copy0MBB: > // %FalseValue = ... > diff --git a/lib/Target/BPF/BPFInstrInfo.td b/lib/Target/BPF/BPFInstrInfo.td > index f683578..56f0f9c 100644 > --- a/lib/Target/BPF/BPFInstrInfo.td > +++ b/lib/Target/BPF/BPFInstrInfo.td > @@ -464,7 +464,7 @@ let usesCustomInserter = 1 in { > (ins GP...

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've tagged the 5.0.1-rc2 release, go ahead and start testing and report your results. -Tom

...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 halves from the targ...

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

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