search for: noencod

On Tue, 30 May 2017, Nemanja Ivanovic wrote: > This is typically accomplished with something like PPC's `RegConstraint` and > `NoEncode`. You can see examples of it 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...

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))]>, >>

...t these nodes in your <TargetName>ISelDAGToDAG.cpp. On Tue, May 30, 2017 at 3:01 PM, Dr. ERDI Gergo <gergo at erdi.hu> wrote: > On Tue, 30 May 2017, Nemanja Ivanovic wrote: > > This is typically accomplished with something like PPC's `RegConstraint` >> and >> `NoEncode`. You can see examples of it 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). >> F...

...D, ptr_rc:$ea_result), (ins memri: $addr), +def LBZU : DForm_1<35, (outs GPRC:$rD, ptr_rc_wrapper:$ea_result), (ins memri:$addr), "lbzu $rD, $addr", LdStLoadUpd, []>, RegConstraint<"$addr.reg = $ea_result">, NoEncode<"$ea_result">; I now get an "Unknown node flavor used in pattern: ptr_rc_wrapper". I.e.: llvm[3]: Building PPC.td instruction information with tblgen STBU: (set ptr_rc_wrapper:<empty>:$ea_res, (ist:iPTR GPRC:i32:$rS, ptr_rc_wrapper:iPTR:$ptrreg, iaddroff:iPTR: $...

Hi all, I've been poking at AsmParser support for powerpc64 (ppc64-elf-linux-abi) and have run into some behavior I don't understand with the ptr_rc references coming out of the PPC*.td files when generating the asm-matcher files. For instance : $ ./build/bin/llvm-tblgen llvm/lib/Target/PowerPC/PPC.td -I ~/llvm-head/llvm/include -I ~/llvm-head/llvm/lib/Target/PowerPC/ -gen-asm-matcher

...e, the PowerPC backend has a pre-increment store encoded like this: def STDUX : XForm_8<31, 181, (outs ptr_rc_nor0:$ea_res), (ins g8rc:$rS, memrr:$dst), "stdux $rS, $dst", LdStSTDU, []>, RegConstraint<"$dst.ptrreg = $ea_res">, NoEncode<"$ea_res">; } def : Pat<(pre_store i64:$rS, iPTR:$ptrreg, iPTR:$ptroff), (STDUX $rS, $ptrreg, $ptroff)>; Note that the instruction has a pseudo-output operand $ea_res which is constrained and not encoded. You are correct, however, that this does not encode any inf...

...d has a pre-increment store encoded like this: > > def STDUX : XForm_8<31, 181, (outs ptr_rc_nor0:$ea_res), (ins g8rc:$rS, memrr:$dst), > "stdux $rS, $dst", LdStSTDU, []>, > RegConstraint<"$dst.ptrreg = $ea_res">, NoEncode<"$ea_res">; > } > > def : Pat<(pre_store i64:$rS, iPTR:$ptrreg, iPTR:$ptroff), > (STDUX $rS, $ptrreg, $ptroff)>; > > Note that the instruction has a pseudo-output operand $ea_res which is constrained and not encoded. You are correct, however, that...

Hi Hal, Our Architecture has indirect move instruction which increments the pointer implicitly and the target only has i8 type values. So the load of i16 will be converted to two i8 target loads wherein after the first load instruction, the pointer to the first i8 address will automatically increment to point to the next i8 value. So the post increment nature is in the Target. A normal

...mri: > $addr), > +def LBZU : DForm_1<35, (outs GPRC:$rD, ptr_rc_wrapper:$ea_result), (ins > memri:$addr), > "lbzu $rD, $addr", LdStLoadUpd, > []>, RegConstraint<"$addr.reg = $ea_result">, > NoEncode<"$ea_result">; > > > I now get an "Unknown node flavor used in pattern: ptr_rc_wrapper". > I.e.: > llvm[3]: Building PPC.td instruction information with tblgen > STBU: (set ptr_rc_wrapper:<empty>:$ea_res, (ist:iPTR GPRC:i32:$rS, > ptr_rc_wra...