search for: ppcinstrinfo

...w things to modify in lib/Target/PowerPC with a lot of "if (!isDarwin)". There are some places where I need help before saying the port is complete. I attached the diff file as a reference 1) In order to generate a creqv instruction before a vararg call, I created a new instruction in PPCInstrInfo.td: SETCR which uses the new XForm_1_ext format. It does not use the XForm_1 format because I wanted to give only one register as operand. I'm not sure if this is the correct way to do this, but it works. 2) Line 369 of PPCInstrInfo.td, we declare the non-callee saved registers. However, Lin...

...vm_void_ty, llvm_ptr_ty], [IntrWriteMem]>; > def int_ppc_dcbzl : Intrinsic<[llvm_void_ty, llvm_ptr_ty], [IntrWriteMem]>; > + > + // sync instruction > + def int_ppc_sync : Intrinsic<[llvm_void_ty], [IntrWriteMem]>; > } > > > Index: lib/Target/PowerPC/PPCInstrInfo.td > =================================================================== > --- lib/Target/PowerPC/PPCInstrInfo.td (revision 54985) > +++ lib/Target/PowerPC/PPCInstrInfo.td (working copy) > @@ -773,6 +773,10 @@ > [(store F8RC:$frS, xaddr:$dst)]>; > } >...

...def int_ppc_dcbz : Intrinsic<[llvm_void_ty, llvm_ptr_ty], [IntrWriteMem]>; def int_ppc_dcbzl : Intrinsic<[llvm_void_ty, llvm_ptr_ty], [IntrWriteMem]>; + + // sync instruction + def int_ppc_sync : Intrinsic<[llvm_void_ty], [IntrWriteMem]>; } Index: lib/Target/PowerPC/PPCInstrInfo.td =================================================================== --- lib/Target/PowerPC/PPCInstrInfo.td (revision 54985) +++ lib/Target/PowerPC/PPCInstrInfo.td (working copy) @@ -773,6 +773,10 @@ [(store F8RC:$frS, xaddr:$dst)]>; } +let isBarrier = 1 in +def SYNC :...

...def int_ppc_dcbz : Intrinsic<[llvm_void_ty, llvm_ptr_ty], [IntrWriteMem]>; def int_ppc_dcbzl : Intrinsic<[llvm_void_ty, llvm_ptr_ty], [IntrWriteMem]>; + + // sync instruction + def int_ppc_sync : Intrinsic<[llvm_void_ty], [IntrWriteMem]>; } Index: lib/Target/PowerPC/PPCInstrInfo.td =================================================================== --- lib/Target/PowerPC/PPCInstrInfo.td (revision 54985) +++ lib/Target/PowerPC/PPCInstrInfo.td (working copy) @@ -773,6 +773,10 @@ [(store F8RC:$frS, xaddr:$dst)]>; } +let isBarrier = 1 in +def SYNC :...

...et/PowerPC with a lot of "if (!isDarwin)". > > There are some places where I need help before saying the port is > complete. I attached the diff file as a reference > > 1) In order to generate a creqv instruction before a vararg call, I > created a new instruction in PPCInstrInfo.td: SETCR which > uses the new XForm_1_ext format. It does not use the XForm_1 format > because I wanted to give only one register as operand. > I'm not sure if this is the correct way to do this, but it works. > > 2) Line 369 of PPCInstrInfo.td, we declare the non-callee saved...

...that are very similar to what you're after in > PPC's load/store with update forms (i.e. load a value and update the base register > with the effective address - these are used for pre-increment loads/stores). > For example: the definition of LBZU and friends in lib/Target/PowerPC/PPCInstrInfo.td. > For a simpler example of just the `RegConstraint` usage (as it doesn't use a compound > node like PPC's address nodes), you can look at all the fused multiply-add such as > XSMADDADP in lib/Target/PowerPC/PPCInstrVSX.td. > > Hope this helps. Thanks! However, none of...

...rwin)". >> >> >> There are some places where I need help before saying the port is >> complete. I attached the diff file as a reference >> >> >> 1) In order to generate a creqv instruction before a vararg call, I >> created a new instruction in PPCInstrInfo.td: SETCR which >> >> uses the new XForm_1_ext format. It does not use the XForm_1 format >> because I wanted to give only one register as operand. >> >> I'm not sure if this is the correct way to do this, but it works. >> >> >> 2) Line 369 of PP...

...struction it has to be expanded to a library call or lowered to something the ppc backend can understand? If it is possible to add the functionality of these functions to a library: Where is this library and how can these functions be added? Is it correct that entries in IntrinsicsPowerPC.td and PPCInstrInfo.td files have to be done to make these new intrinsics known? "migrate_begin" is an instruction with a variable argument list. Is there some special handling necessary to add variable argument functions? I would be thankful for any hints regarding this PowerPC backend adaptation. Thank...

...$rA, $rB\n\tbne- La${label}_exit", [(PPCcmp_unres GPRC:$rA, GPRC:$rB, imm:$label)]>; } ...and I can't figure out the syntax for that. Any suggestions? Cheers, Gary -- http://gbenson.net/ -------------- next part -------------- Index: lib/Target/PowerPC/PPCInstrInfo.td =================================================================== --- lib/Target/PowerPC/PPCInstrInfo.td (revision 52823) +++ lib/Target/PowerPC/PPCInstrInfo.td (working copy) @@ -531,8 +531,8 @@ PPC970_DGroup_Single; // Atomic operations. -def LWARX : Pseudo<(outs...

...making lldb do not set the correct breakpoint, so the execution does not stop at next line, which should be the "step over" behavior. The variable "Flags" for the disassembled instruction does not have the branch flag. I have tried to change the file "/lib/Target/PowerPC/PPCInstrInfo.td", adding "isBranch = 1" for the instruction "bc 4, $bi, $dst", but had not effect. Comparing with x86_64, building the same cpp file, the instruction "jne 0x4005eb" has the branch flag, which identifies it as a branch instruction. Where is the definition t...

...iew. This will make it much more likely that your pieces will be applied in a timely fashion :). This will also let you get pieces in before the whole thing is "done". > 1) In order to generate a creqv instruction before a vararg call, I created a > new instruction in PPCInstrInfo.td: SETCR which > uses the new XForm_1_ext format. It does not use the XForm_1 format because I > wanted to give only one register as operand. > I'm not sure if this is the correct way to do this, but it works. Yep, that's the right way to go. > 2) Line 369 of PPCInstrInfo.td...

...em]>; >> def int_ppc_dcbzl : Intrinsic<[llvm_void_ty, llvm_ptr_ty], >> [IntrWriteMem]>; >> + >> + // sync instruction >> + def int_ppc_sync : Intrinsic<[llvm_void_ty], [IntrWriteMem]>; >> } >> >> >> Index: lib/Target/PowerPC/PPCInstrInfo.td >> =================================================================== >> --- lib/Target/PowerPC/PPCInstrInfo.td (revision 54985) >> +++ lib/Target/PowerPC/PPCInstrInfo.td (working copy) >> @@ -773,6 +773,10 @@ >> [(store F8RC:$frS, xaddr:$dst)]...

On Aug 19, 2008, at 7:18 AMPDT, Gary Benson wrote: > Hi all, > > I'm trying to implement llvm.memory.barrier on PowerPC. I've modelled > my patch (attached) on the implementation in X86, but when I try and > compile my test file (also attached) with llc I get the error "Cannot > yet select: 0x10fa4ad0: ch = MemBarrier 0x10fa4828, 0x10fa4c68, > 0x10fa4be0,

...r reference[1] memri is defined as: def memri :Operand<iPTR> { let PrintMethod = "printMemRegImm"; let MIOperandInfo = (ops dispRI:$imm, ptr_rc_nor0:$reg); let EncoderMethod = "getMemRIEncoding";} [1] https://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/PowerPC/PPCInstrInfo.td?view=markup -- * Anitha* -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130407/e6eb650a/attachment.html>

This looks OK to check in, do you have write access? On Aug 21, 2008, at 6:38 AMPDT, Gary Benson wrote: > Dale Johannesen wrote: >> On Aug 19, 2008, at 7:18 AMPDT, Gary Benson wrote: >>> I'm trying to implement llvm.memory.barrier on PowerPC. I've >>> modelled my patch (attached) on the implementation in X86, but >>> when I try and compile my test

On Sun, 28 May 2017, David Chisnall wrote: >> let Constraints = "@earlyclobber $reg" in >> def LDWRdPtr : Pseudo<(outs DREGS:$reg), >> (ins PTRREGS:$ptrreg), >> "ldw\t$reg, $ptrreg", >> [(set i16:$reg, (load i16:$ptrreg))]>, >>

...will not be pipelined. However in reality it is not ignored and is being considered for pipelining. I implemented this function in my own backend, and put an instruction there that I want to be ignored, but still this instruction end up trying to be pipelined. I implemented the same way as in PPCInstrInfo.cpp, and I think it has the same bug. Is this a bug, or am I forgetting something? Kind regards, Sander Ruben

The reason the ones in PPCInstrInfo.td don't have the patterns to match is the reason they are more analogous to your problem. Namely, tblgen does not have a way to produce nodes with more than one result. The load-with-update instructions do exactly that - one of the inputs is also an output, but the other output is independent...

...<iPTR> { > > let PrintMethod = "printMemRegImm"; > > let MIOperandInfo = (ops dispRI:$imm, ptr_rc_nor0:$reg); > > let EncoderMethod = "getMemRIEncoding"; > > } > > [1] > https://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/PowerPC/PPCInstrInfo.td?view=markup > -- > /* Anitha*/ > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HT...

...:Operand<iPTR> { > > let PrintMethod = "printMemRegImm"; > > let MIOperandInfo = (ops dispRI:$imm, ptr_rc_nor0:$reg); > > let EncoderMethod = "getMemRIEncoding"; > } > > [1] > https://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/PowerPC/PPCInstrInfo.td?view=markup > -- > Anitha > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > _______________________________...