search for: setindexedloadact

...with the final address. > > 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,...

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,

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

...ormat and pattern for this > type of instructions. > > How to encode the information that the pointer is incremented? As you seem to be aware, LLVM has patterns specifically to match pre/post increment loads and stores (post_store). In your *ISelLowering.cpp file, you'll need to call setIndexedLoadAction(ISD::POST_INC, <type>, Legal), and the same for setIndexedStoreAction. Then you'll need to implement a getPostIndexedAddressParts function in that same file (you can look in the ARM backend for an example). If you can select your indirect moves using TableGen patterns, then you can pro...

Hi, We have an architecture where the indirect move instruction implicitly increments the pointer value after the move. We have Instruction format and pattern for this type of instructions. How to encode the information that the pointer is incremented? Thanks and regards, Shashidhar

...rn for this >> type of instructions. >> >> How to encode the information that the pointer is incremented? > As you seem to be aware, LLVM has patterns specifically to match pre/post increment loads and stores (post_store). In your *ISelLowering.cpp file, you'll need to call setIndexedLoadAction(ISD::POST_INC, <type>, Legal), and the same for setIndexedStoreAction. Then you'll need to implement a getPostIndexedAddressParts function in that same file (you can look in the ARM backend for an example). If you can select your indirect moves using TableGen patterns, then you can pro...

Hi, I'm trying to enable the pre-decrementing and post-incrementing based addressing modes for my target. So far without any success :( I enabled these modes in my TargetLowering class using setIndexedLoadAction and setIndexedStoreAction calls. I also defined getPreIndexedAddressParts and getPostIndexedAddressParts. And I can see that DAGCombiner::CombineToPostIndexedLoadStore is invoked. But this function never does any replacements and very seldomly invoke getPostIndexedAddressParts and so on, even in...

Hi Chris, --- Chris Lattner <sabre at nondot.org> wrote: > On Wed, 29 Nov 2006, Roman Levenstein wrote: > > Thanks, this is a good idea. > > > > But I cannot figure out how to make a machine function pass run > > _BEFORE_ the RA. I guess I'm missing something very obvious. > > In your target's TargetMachine::addInstSelector method, add it to the

...t; >> > >> How to encode the information that the pointer is incremented? > > As you seem to be aware, LLVM has patterns specifically to match > > pre/post increment loads and stores (post_store). In your > > *ISelLowering.cpp file, you'll need to call > > setIndexedLoadAction(ISD::POST_INC, <type>, Legal), and the same > > for setIndexedStoreAction. Then you'll need to implement a > > getPostIndexedAddressParts function in that same file (you can > > look in the ARM backend for an example). If you can select your > > indirect moves u...

...ut load/store incrementing address modes I’ve implemented something similar, though maybe not similar enough to be able to help you. My target supports 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 mor...

...;>>> How to encode the information that the pointer is incremented? >>> As you seem to be aware, LLVM has patterns specifically to match >>> pre/post increment loads and stores (post_store). In your >>> *ISelLowering.cpp file, you'll need to call >>> setIndexedLoadAction(ISD::POST_INC, <type>, Legal), and the same >>> for setIndexedStoreAction. Then you'll need to implement a >>> getPostIndexedAddressParts function in that same file (you can >>> look in the ARM backend for an example). If you can select your >>> indi...

...mm 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 instruction selection for masked_gather and masked_scatter . Best regards, Alex...

...emented “isLegalAddressingMode”, but it turned to be virtually identical to the default one except for the smaller immediate sizes, so I think it doesn’t make much difference. Post/Pre increment addressing mode is not supported in my architecture so this is reflected, and I haven’t either added the setIndexedLoadAction calls to my TargetLowering constructor. I also created my own TargetTransformInfo implementation based on the ARM code, which works fine as the functions get diligently called, but I found that it’s not of much help because it doesn’t have the necessary hooks to solve this issue) So any additio...

I am trying to implement vector type load/store with post-increment for an out of tree backend. I see that that ARM NEON support such load/store so I am using ARM NEON as an example of what to do. The problem is I can't get any C or C++ code example to actually generate vector load/store with post increment. I am talking about something like this: vldr d16, [sp, #8] Does anybody

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 -

I come across a situation that I am having a hard time to understand. When I compile the following code : char *tst( char *dest, const char *src, unsigned int len ) { for (int i=0 ; i<len ; i++) { dest[i] = src[i]; } return dest; } Clang generates this for the ‘for’ body: for.body: ; preds = %for.cond %arrayidx = getelementptr inbounds i8,