search for: ppcisd

...t<0>, SDTCisPtrTy<1> +]>; +def SDT_PPCstcx : SDTypeProfile<0, 2, [ + SDTCisInt<0>, SDTCisPtrTy<1> +]>; + def SDT_PPCTC_ret : SDTypeProfile<0, 2, [ SDTCisPtrTy<0>, SDTCisVT<1, i32> ]>; @@ -143,12 +149,22 @@ def PPCstbrx : SDNode<"PPCISD::STBRX", SDT_PPCstbrx, [SDNPHasChain, SDNPMayStore]>; +// Atomic operations +def PPCatomic_load_add : SDNode<"PPCISD::ATOMIC_LOAD_ADD", + SDT_PPCatomic_load_add, + [SDNPHasChain, SDNPMay...

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

...t<0>, SDTCisPtrTy<1> +]>; +def SDT_PPCstcx : SDTypeProfile<0, 2, [ + SDTCisInt<0>, SDTCisPtrTy<1> +]>; + def SDT_PPCTC_ret : SDTypeProfile<0, 2, [ SDTCisPtrTy<0>, SDTCisVT<1, i32> ]>; @@ -143,12 +149,22 @@ def PPCstbrx : SDNode<"PPCISD::STBRX", SDT_PPCstbrx, [SDNPHasChain, SDNPMayStore]>; +// Atomic operations +def PPCatomic_load_add : SDNode<"PPCISD::ATOMIC_LOAD_ADD", + SDT_PPCatomic_load_add, + [SDNPHasChain, SDNPMay...

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

...t<0>, SDTCisPtrTy<1> +]>; +def SDT_PPCstcx : SDTypeProfile<0, 2, [ + SDTCisInt<0>, SDTCisPtrTy<1> +]>; + def SDT_PPCTC_ret : SDTypeProfile<0, 2, [ SDTCisPtrTy<0>, SDTCisVT<1, i32> ]>; @@ -143,12 +149,22 @@ def PPCstbrx : SDNode<"PPCISD::STBRX", SDT_PPCstbrx, [SDNPHasChain, SDNPMayStore]>; +// Atomic operations +def PPCatomic_load_add : SDNode<"PPCISD::ATOMIC_LOAD_ADD", + SDT_PPCatomic_load_add, + [SDNPHasChain, SDNPMay...

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

...t<0>, SDTCisPtrTy<1> +]>; +def SDT_PPCstcx : SDTypeProfile<0, 2, [ + SDTCisInt<0>, SDTCisPtrTy<1> +]>; + def SDT_PPCTC_ret : SDTypeProfile<0, 2, [ SDTCisPtrTy<0>, SDTCisVT<1, i32> ]>; @@ -143,12 +149,22 @@ def PPCstbrx : SDNode<"PPCISD::STBRX", SDT_PPCstbrx, [SDNPHasChain, SDNPMayStore]>; +// Atomic operations +def PPCatomic_load_add : SDNode<"PPCISD::ATOMIC_LOAD_ADD", + SDT_PPCatomic_load_add, + [SDNPHasChain, SDNPMay...

...terLocation(). On X86 it's implemented in terms of address space (similar to getStackCooikeLocation), but on AArch64 it's implemented in terms of a target specific AArch64ISD::THREAD_POINTER and Intrinsic::aarch64_thread_pointer. To make the fix least surprising, I can either do: 1) Create PPCISD::THREAD_POINTER and Intrinsic::ppc_thread_pointer and do similar things aarch64 does; or 2) Don't create PPCISD::THREAD_POINTER, but directly calls llvm.read_register intrinsic in ppc's getStackCookieLocation(). This is the way that requires least change; or 3) Create a generic ISD::GET_GLO...

...everything's Ok. There is one significant bug that fell out from this, which caused some macho function calls to be compiled with ELF ABI semantics. I checked in this patch to fix it: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070219/045027.html I think you have to split PPCISD::CALL into PPCISD::CALL_ELF and PPCISD::CALL_Macho, like you do for BCTRL. There were also a couple missing patterns, together these caused some nightly tester failures on darwin. >> I applied the patches after some cleanups. Please keep code within 80 >> columns, please don't...

Hi Chris, Chris Lattner wrote: > Sorry for the delay, > > No problem. Plus the reviewing may have taken some time. So thx a lot for committing. I talked to Jim who said he wanted to commit his changes before mine -- I hope everything's Ok. > I applied the patches after some cleanups. Please keep code within 80 > columns, please don't use nested ?: expressions without

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 pure, so that derived class authors are forced to think how...

...ere is one significant bug that fell out from this, which caused some > macho function calls to be compiled with ELF ABI semantics. I checked in > this patch to fix it: > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070219/045027.html > > I think you have to split PPCISD::CALL into PPCISD::CALL_ELF and > PPCISD::CALL_Macho, like you do for BCTRL. There were also a couple > missing patterns, together these caused some nightly tester failures on > darwin. > > Yes, you are right. Here's a patch to fix the missing patterns. There is now a CAL...

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 >

...t0, Register:i64 %vreg0 t16: i32,ch = load<LD1[%ptr](tbaa=<0x10023c9f448>), anyext from i8> t0, t2, undef:i64 t15: v16i8 = BUILD_VECTOR t16, t16, t16, t16, t16, t16, t16, t16, t16, t16, t16, t16, t16, t16, t16, t16 t11: ch,glue = CopyToReg t0, Register:v16i8 %V2, t15 t12: ch = PPCISD::RET_FLAG t11, Register:v16i8 %V2, t11:1 and the following pattern that I'd like to match: def ScalarLoads { dag Li8 = (i32 (extloadi8 xoaddr:$src)); } def : Pat<(v16i8 (build_vector ScalarLoads.Li8, ScalarLoads.Li8, ScalarLoads.Li8, ScalarLoads.Li8,...

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

...;test:entry' SelectionDAG has 9 nodes: t0: ch = EntryToken t3: i64 = Constant<0> t2: i64,ch = CopyFromReg t0, Register:i64 %vreg0 t5: v4i32,ch = load<LD16[%0](tbaa=<0x10038f18a98>)> t0, t2, undef:i64 t7: ch,glue = CopyToReg t0, Register:v4i32 %V2, t5 t8: ch = PPCISD::RET_FLAG t7, Register:v4i32 %V2, t7:1 What I would like to do is emit efficient code for cases where the parameter pointer has the same alignment requirements as the load and emit the conservative but less efficient code in other cases. Nemanja -------------- next part -------------- An HTML att...