search for: ea_r

...ode this > information? No, at the MI level, we can currently only encode that there is a constraint that some input operand must be the same as some output operand. For example, 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,...

...information? > No, at the MI level, we can currently only encode that there is a constraint that some input operand must be the same as some output operand. For example, 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:$ptrof...

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

...r_rc within a larger blob; I'm getting different error messages out, but can't tell whether or not this is progress. Using the memri definitions as inspiration: +def ptr_rc_wrapper : Operand<iPTR> { + let PrintMethod = "printMemRegImm"; + let MIOperandInfo = (ops ptr_rc:$ea_result); +} And then swapping out the ptr_rc: references like so: -def LBZU : DForm_1<35, (outs GPRC:$rD, 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...

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

...39;m getting different error messages out, but > can't tell whether or not this is progress. > > Using the memri definitions as inspiration: > +def ptr_rc_wrapper : Operand<iPTR> { > + let PrintMethod = "printMemRegImm"; > + let MIOperandInfo = (ops ptr_rc:$ea_result); > +} > > And then swapping out the ptr_rc: references like so: > > -def LBZU : DForm_1<35, (outs GPRC:$rD, ptr_rc:$ea_result), (ins memri: > $addr), > +def LBZU : DForm_1<35, (outs GPRC:$rD, ptr_rc_wrapper:$ea_result), (ins > memri:$addr), >...