search for: mtctr

..." > "L00000000001$pb": > mflr r2 > mtlr r5 > addis r4,r2,ha16(L_Array$non_lazy_ptr-"L00000000001$pb") > li r2,0 > lwz r9,lo16(L_Array$non_lazy_ptr-"L00000000001$pb")(r4) > li r4,1000 > mtctr r4 > L9: > lwzx r7,r2,r9 ; load > add r6,r7,r3 ; add > stwx r6,r2,r9 ; store > addi r2,r2,4 ; Increment pointer > bdnz L9 ; Decrement count register, branch while not zero > blr...

On Fri, 12 May 2006, Ralph Corderoy wrote: >> If you don't *know* that all (e.g.) function pointers to this code are >> dead (which means that execution could come back to the function), you >> should use the ExecutionEngine::recompileAndRelinkFunction(F) method. > > recompileAndRelinkFunction() overwrites the old machine code with a > branch to the new. Is it

...ment this API correctly... if it doesn't, that's a bug: please > report it! No, EmitBranchToAt() always emits 16 bytes. AtI[0] = BUILD_LIS(12, Addr >> 16); // lis r12, hi16(address) AtI[1] = BUILD_ORI(12, 12, Addr); // ori r12, r12, low16(address) AtI[2] = BUILD_MTCTR(12); // mtctr r12 AtI[3] = BUILD_BCTR(isCall); // bctr/bctrl but I understand now how startFunctionStub() is given StubSize and on PowerPC it's 16 so there's no problem. Cheers, Ralph.

...ose, Chris' solution is functional enough. However, I looked into llvm-gcc code and the switch instruction switches for all possible labels defined in the method. Does LLVM is smart enough to realize that it switches on the address of a label, therefore only has to generate a jmp in x86 or a {mtctr, bctr} couple in powerpc? Nicolas

...on is functional enough. However, I looked into llvm-gcc > code and the switch instruction switches for all possible labels defined > in the method. Does LLVM is smart enough to realize that it switches on > the address of a label, therefore only has to generate a jmp in x86 or a > {mtctr, bctr} couple in powerpc? I'm not sure what you mean. We do reasonable optimization of switch statements, but I'm sure there are cases we miss. If so, please let us know, so we can add them to lib/Target/README.txt -Chris -- http://nondot.org/sabre/ http://llvm.org/

...on. This is the case for 32-bit Linux PowerPC, and, from looking at the code in LLVM it seems to be the case for both 32- and 64-bit Darwin. A call on these platforms looks like this, assuming the function pointer is in rX, and all arguments to the call have been put in the appropriate places: mtctr rX bctrl Simple. On 64-bit Linux PowerPC, however, a function pointer in C is the address of a function descriptor, a structure containing three pointers: - The first pointer contains the address of the entry point of the function. - The second pointer contains the TOC base address for th...

On Jan 11, 2007, at 7:14 AM, Chris Lattner wrote: > On Wed, 10 Jan 2007, Nicolas Geoffray wrote: >> I was looking for an indirect branch instruction in llvm, which would >> not take a BasicBlock as argument, but a value. Reid told me on >> IRC that >> there is no such instruction in llvm. >> >> Is this deliberate? Or did you never face the need of this

...:SHL"; - case PPCISD::EXTSW_32: return "PPCISD::EXTSW_32"; - case PPCISD::STD_32: return "PPCISD::STD_32"; - case PPCISD::CALL_ELF: return "PPCISD::CALL_ELF"; - case PPCISD::CALL_Macho: return "PPCISD::CALL_Macho"; - case PPCISD::MTCTR: return "PPCISD::MTCTR"; - case PPCISD::BCTRL_Macho: return "PPCISD::BCTRL_Macho"; - case PPCISD::BCTRL_ELF: return "PPCISD::BCTRL_ELF"; - case PPCISD::RET_FLAG: return "PPCISD::RET_FLAG"; - case PPCISD::MFCR: return "PPCI...

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

...:SHL"; - case PPCISD::EXTSW_32: return "PPCISD::EXTSW_32"; - case PPCISD::STD_32: return "PPCISD::STD_32"; - case PPCISD::CALL_ELF: return "PPCISD::CALL_ELF"; - case PPCISD::CALL_Macho: return "PPCISD::CALL_Macho"; - case PPCISD::MTCTR: return "PPCISD::MTCTR"; - case PPCISD::BCTRL_Macho: return "PPCISD::BCTRL_Macho"; - case PPCISD::BCTRL_ELF: return "PPCISD::BCTRL_ELF"; - case PPCISD::RET_FLAG: return "PPCISD::RET_FLAG"; - case PPCISD::MFCR: return "PPCI...

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

...:SHL"; - case PPCISD::EXTSW_32: return "PPCISD::EXTSW_32"; - case PPCISD::STD_32: return "PPCISD::STD_32"; - case PPCISD::CALL_ELF: return "PPCISD::CALL_ELF"; - case PPCISD::CALL_Macho: return "PPCISD::CALL_Macho"; - case PPCISD::MTCTR: return "PPCISD::MTCTR"; - case PPCISD::BCTRL_Macho: return "PPCISD::BCTRL_Macho"; - case PPCISD::BCTRL_ELF: return "PPCISD::BCTRL_ELF"; - case PPCISD::RET_FLAG: return "PPCISD::RET_FLAG"; - case PPCISD::MFCR: return "PPCI...

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:

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

...:SHL"; - case PPCISD::EXTSW_32: return "PPCISD::EXTSW_32"; - case PPCISD::STD_32: return "PPCISD::STD_32"; - case PPCISD::CALL_ELF: return "PPCISD::CALL_ELF"; - case PPCISD::CALL_Macho: return "PPCISD::CALL_Macho"; - case PPCISD::MTCTR: return "PPCISD::MTCTR"; - case PPCISD::BCTRL_Macho: return "PPCISD::BCTRL_Macho"; - case PPCISD::BCTRL_ELF: return "PPCISD::BCTRL_ELF"; - case PPCISD::RET_FLAG: return "PPCISD::RET_FLAG"; - case PPCISD::MFCR: return "PPCI...

Sadly the latest optimization broke completely everything. The asm code isn't gas compliant. the libFLAC linker script has a typo, disabling the asm optimization and/or altivec won't let a correct build anyway. Instant fixes for the asm stuff: sed -i -e"s:;:\#:" on the lpc_asm.s to load address instead of addis+ori you could use lis and la and PLEASE use the @l(register)

...enough. However, I looked into llvm-gcc >> code and the switch instruction switches for all possible labels defined >> in the method. Does LLVM is smart enough to realize that it switches on >> the address of a label, therefore only has to generate a jmp in x86 or a >> {mtctr, bctr} couple in powerpc? >> > > I'm not sure what you mean. We do reasonable optimization of switch > statements, but I'm sure there are cases we miss. If so, please let us > know, so we can add them to lib/Target/README.txt > > Two jumps are executed wh...