Displaying 6 results from an estimated 6 matches for "ea_res".
Did you mean:
__res
2013 Oct 01
0
[LLVMdev] Post Increment Indirect Move Instructions
...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, $p...
2013 Oct 08
1
[LLVMdev] Post Increment Indirect Move Instructions
...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)...
2013 Oct 01
2
[LLVMdev] Post Increment Indirect Move Instructions
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
2012 Sep 19
0
[LLVMdev] "Unknown node flavor ..." Was: Re: tablegen and ptr_rc: PointerLikeRegClass
...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,...
2012 Sep 14
2
[LLVMdev] tablegen and ptr_rc: PointerLikeRegClass
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
2012 Nov 15
3
[LLVMdev] Tablegen and ptr_rc: PointerLikeRegClass
...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),
>...