search for: pre_stor

Hi, How do "Pat" operands get matched? I am trying to follow the example given in http://llvm.org/docs/CodeGenerator.html#selectiondag-process In the latest trunk of ppcintrinfo.td following pattern is defined: def : Pat<(pre_store i32:$rS, iPTR:$ptrreg, iaddroff:$ptroff), (STWU $rS, iaddroff:$ptroff, $ptrreg)>; I understand that input operand list i.e. ins of stwu should get matched with the given pre_store. But I am confused as to how "ptroff" and "ptrreg" get matched with "memri...

...> > memri is just describing that the address contains two components, an > immediate and a register, and how to handle 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 i...

...; > How do "Pat" operands get matched? I am trying to follow the example > given in http://llvm.org/docs/CodeGenerator.html#selectiondag-process > > In the latest trunk of ppcintrinfo.td <http://ppcintrinfo.td> > following pattern is defined: > > def : Pat<(pre_store i32:$rS, iPTR:$ptrreg, iaddroff:$ptroff), > (STWU $rS, iaddroff:$ptroff, $ptrreg)>; > > I understand that input operand list i.e. ins of stwu should get > matched with the given pre_store. But I am confused as to how > "ptroff" and "ptrreg" ge...

What about things like pre_store and post_store, though? If there was a pre_load and post_load this would largely solve the problem. Of course there are a wealth of addressing modes for the 68k, but they should be able to be dealt with like this I think? -----Original Message----- From: Dr D. Chisnall [mailto:dc552 at hermes.ca...

...re out how to map more complex CISC instructions now. For example on the 68000, you have things like -- add.w (a0)+,(a1)+ So that equates to: temp1 = load a0 add 2, a0 temp2 = load a1 temp1 = add temp1, temp2 store temp1, a1 add 2, a1 How do I express that in a form for LLVM? I see things like pre_store and post_store, but I cant find anything in the way of documentation about this. And there doesn't appear to be a pre_load and post_load matching pair or anything like that... Thanks!

...ed 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 information on the relationship between the input and outp...

...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 information on the relationship between the...

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

...mbiner calls into the backend using the function PPCTargetLowering::getPreIndexedAddressParts, which tells DAGCombine when it can combine the the load and the increment into a singe pre/post-increment load or store. The pre-increment stores are instruction-selected in PPCInstrInfo.td (look for the pre_store patterns). The pre-increment loads are selected in PPCISelDAGToDAG.cpp (TableGen can't yet handle instructions returning multiple outputs), look for the code just after ISD::PRE_INC around line 1060. >From your formula below, it looks like you have a pre-increment load. -Hal > >...

Hi all, I'm trying to continue an existing m68k backend for LLVM. I'm completely new to LLVM development so I've been muddling my way through mostly by trial and error and using existing back ends for reference. I'm trying to implement code to allow calling. I am compiling this C code -- typedef unsigned int uint32_t; typedef char int8_t; uint32_t foo(uint32_t x, int8_t y) {

Hi Steve, Thanks for the tip regarding MIOperandInfo, I didn't think of that part of the tablegen description. Sadly, I did actually mean: r1 = *(i0 += m0). So increment i0 by m0. Read memory the memory location "pointed" to by i0. Store in r1. Sadly I am not too familiar with compiler terminology, so I don't know if there is a proper term for such a load. On Thu, Oct 23,