search for: pre_inc

...t; > So maybe the PowerPC back end is worth looking at? Yes, and so it ARM (which has both pre- and post-increment loads/stores). For PowerPC, for example, this works as follows: In PPCISelLowering.cpp, we have this: // PowerPC has pre-inc load and store's. setIndexedLoadAction(ISD::PRE_INC, MVT::i1, Legal); setIndexedLoadAction(ISD::PRE_INC, MVT::i8, Legal); setIndexedLoadAction(ISD::PRE_INC, MVT::i16, Legal); setIndexedLoadAction(ISD::PRE_INC, MVT::i32, Legal); setIndexedLoadAction(ISD::PRE_INC, MVT::i64, Legal); setIndexedStoreAction(ISD::PRE_INC, MVT::i1, Legal); setIn...

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,

...two > post increment load. SDNodes can be used to define only one value and > so > the Selection DAG cannot to used to encode the information that the > pointer has been incremented. This is not true. SDNodes can have multiple values. Load SD nodes can have different addressing modes (PRE_INC, POST_INC, etc.) and for PRE_INC and POST_INC, the SDNode returns multiple values. If you look in lib/CodeGen/SelectionDAG/DAGCombiner.cpp in DAGCombiner::CombineToPostIndexedLoadStore you can see how post-increment stores are normally generated (and how to deal with multi-valued nodes). > &gt...

...ncrement load. SDNodes can be used to define only one value and >> so >> the Selection DAG cannot to used to encode the information that the >> pointer has been incremented. > This is not true. SDNodes can have multiple values. Load SD nodes can have different addressing modes (PRE_INC, POST_INC, etc.) and for PRE_INC and POST_INC, the SDNode returns multiple values. If you look in lib/CodeGen/SelectionDAG/DAGCombiner.cpp in DAGCombiner::CombineToPostIndexedLoadStore you can see how post-increment stores are normally generated (and how to deal with multi-valued nodes). > >&...

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

I have a rudimentary implementation for load and store instructions, where the memory address operand is automatically post-incremented when the load or store instruction is issued. However, this is currently coded using custom lowering, and explicit pattern matching in the 'ISelDAGtoDAG' implementation. But it seems to me that I ought to be able to achieve this exclusively using

...rts increment and decrement, both pre and post, by an explicit constant in the range 1 to 8. I didn’t write any custom lowering code, just used setIndexedLoadAction() and setIndexedStoreAction() in my ISelLowering to identify the types and actions, e.g. setIndexedLoadAction(ISD::PRE_INC, MVT::i16, Legal); I didn’t think it was possible to match an indexed load or store using a TableGen pattern because it can’t match instructions with more than one output operand, though maybe things have changed and I’ve not noticed. So, I wrote custom code in my ISelDAGToDAG to match indexed...

...So I guess I need to change all scalar memory operands to i16 or i16imm in the .td specification files. Please let me know if you see a possibility to fix this problem I guess I should do something like: - // Inspired from ARMISelLowering.cpp: for (unsigned im = (unsigned)ISD::PRE_INC; im != (unsigned)ISD::LAST_INDEXED_MODE; ++im) { setIndexedLoadAction(im, MVT::i64, Legal); setIndexedLoadAction(im, MVT::i16, Promote); setIndexedStoreAction(im, MVT::i64, Legal); setIndexedStoreAction(im, MVT::i16, Promote); } - do custom instruct...

Hello. I wanted to inform that I fixed the bug from the previous email. The main reason for the bug was that I thought that the SDNode masked_gather is returning only 1 value, but it returns 2 (hence, I guess, the earlier reported, difficult to follow, error: "Assertion `New->getNumTypes() == 1"). masked_gather returns 2 values because: // SDTypeProfile -