search for: combinetopostindexedloadstor

Hi, I would like to transform a LLVM function containing a load and an add of the base address inside a loop to a post-incremented load. In DAGCombiner.cpp::CombineToPostIndexedLoadStore(), it says it cannot fold the add for instance if it is a predecessor/successor of the load. I find this odd, as this is exactly what I would like to handle: a simple loop with an address that is inremented in each iteration. I am considering using a target intrinsic for this purpose, as the SCEV...

hello, I read that you do implement these operations in your backend some time ago. (http://llvm.1065342.n5.nabble.com/llvm-dev-Questions-about-load-store-incrementing-address-modes-td87577.html). The DAGCombiner::CombineToPostIndexedLoadStore(SDNode *N) function never works for me. Can you show me a code fragment in C which is translated into pre/post dec/inc load/store? Then I will be able to experiment with msp430 (there seems to have the processing of such cases). Or may be I can look at your backend? ___________________________...

On Jan 27, 2011, at 11:13 PM, Jonas Paulsson wrote: > Hi, > > I would like to transform a LLVM function containing a load and an add of the base address inside a loop to a post-incremented load. In DAGCombiner.cpp::CombineToPostIndexedLoadStore(), it says it cannot fold the add for instance if it is a predecessor/successor of the load. I find this odd, as this > is exactly what I would like to handle: a simple loop with an address that is inremented in each iteration. > > I am considering using a target intrinsic for this purpo...

...ointer 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). > >> I think the description that you mentioned will transform the >> addition/subtraction of a pointer and/from a constant into a pointer >> and >> an offset(Please c...

....us69.inc = getelementptr i16* %p_arrayidx.us69.phi, i32 4 <<<<<<<<<<<<<<< Common Ptr %11 = icmp slt i32 %p.next_loopiv.us67, %leftover_lb br i1 %11, label %p.loop_body.us65, label %p.loop_header38.preheader.us84 When it gets to the DAG Combiner, in CombineToPostIndexedLoadStore() two opportunities for post inc are recognized - the load and the store. Now, you can easily see that in this case you would want the store to get the post inc, not the load, but since the DAG combiner simply scans top-down, the opposite happens. So here is the question - do you recognize this...

...st-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 those situations where I would assume it. For example, it does not use these modes for the code like: void test_postinc(int array[], int i) { array[i] = 1; array[i+...

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

...idx.us69.phi, i32 > 4 > <<<<<<<<<<<<<<< Common Ptr > %11 = icmp slt i32 %p.next_loopiv.us67, %leftover_lb > br i1 %11, label %p.loop_body.us65, label > %p.loop_header38.preheader.us84 > > When it gets to the DAG Combiner, in CombineToPostIndexedLoadStore() > two > opportunities for post inc are recognized - the load and the store. > Now, you can easily see that in this case you would want the store to > get > the post inc, not the load, but since the DAG combiner simply scans > top-down, the opposite happens. > > So here...

...t; 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). > > I think the description that you mentioned will transform the > addition/subtraction of a pointer and/from a constant into a pointer > and > an offset(Please correct me if i...

...t; > <<<<<<<<<<<<<<< Common Ptr > > %11 = icmp slt i32 %p.next_loopiv.us67, %leftover_lb > > br i1 %11, label %p.loop_body.us65, label > > %p.loop_header38.preheader.us84 > > > > When it gets to the DAG Combiner, in CombineToPostIndexedLoadStore() > > two opportunities for post inc are recognized - the load and the > > store. > > Now, you can easily see that in this case you would want the store to > > get the post inc, not the load, but since the DAG combiner simply > > scans top-down, the opposite happens....

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

..., 28 Jan 2011 08:56:09 -0800 CC: llvmdev at cs.uiuc.edu To: jnspaulsson at hotmail.com On Jan 27, 2011, at 11:13 PM, Jonas Paulsson wrote:Hi, I would like to transform a LLVM function containing a load and an add of the base address inside a loop to a post-incremented load. In DAGCombiner.cpp::CombineToPostIndexedLoadStore(), it says it cannot fold the add for instance if it is a predecessor/successor of the load. I find this odd, as this is exactly what I would like to handle: a simple loop with an address that is inremented in each iteration. I am considering using a target intrinsic for this purpose, as the SCEV...

----- Original Message ----- > From: "Paul Redmond" <paul.redmond at intel.com> > To: "llvmdev at cs.uiuc.edu Dev" <llvmdev at cs.uiuc.edu> > Sent: Thursday, February 28, 2013 1:30:57 PM > Subject: [LLVMdev] parallel loop metadata simplification > > Hi, > > I've been working on clang codegen for #pragma ivdep and creating the >

Hi, I've been working on clang codegen for #pragma ivdep and creating the llvm.mem.parallel_loop_access metadata seems quite difficult. The main problem is that there are so many places where loads and stores are created and all of them need to be changed when emitting a parallel loop. Note that creating llvm.loop.parallel is not a problem. One option is to modify IRBuilder to enable