Displaying 6 results from an estimated 6 matches for "ptr_rc_nor0".
2013 Apr 07
1
[LLVMdev] Pat operands matching example in ppc
...dle them in the instruction printer.
> The STWU expects a memri operand, and that is what is passed from the Pat.
>
My confusion is how operands of STWU from "Pat pre_store" get matched
with those of memri. It is defined with operand types as:
let MIOperandInfo = (ops dispRI:$imm, ptr_rc_nor0:$reg);
while Pat is defined as:
def : Pat<(pre_store i32:$rS, iPTR:$ptrreg, iaddroff:$ptroff),
(STWU $rS, iaddroff:$ptroff, $ptrreg)>;
So now how iPTR:$ptrreg and iaddroff:$ptroff get matched with
ptr_rc_nor0:$reg and dispRI:$imm respectively? I mean the types are
not exactl...
2013 Apr 07
2
[LLVMdev] Pat operands matching example in ppc
...e given pre_store. But I am confused as to how "ptroff" and
"ptrreg" get matched with "memri" used in STWU?
For 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/a...
2013 Apr 07
0
[LLVMdev] Pat operands matching example in ppc
...> "ptroff" and "ptrreg" get matched with "memri" used in STWU?
>
>
> For 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*/
>
>
> _______________________________________________
> LLVM Devel...
2013 Oct 01
0
[LLVMdev] Post Increment Indirect Move Instructions
...ny way to encode 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...
2013 Oct 08
1
[LLVMdev] Post Increment Indirect Move Instructions
...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:...
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