search for: getpreindexedaddresspart

...alue(); > if (OtherUses[i]->getOpcode() == ISD::SUB && OffsetIdx == 1) > CNV += OV; > else > CNV -= OV; > > perhaps something here is not quite right. I suspect that the first snippet (where OV is inverted) is wrong because ARM implementation of getPreIndexedAddressParts inverts Offset for pre-decrement case, both for ARM and Thumb2, in getARMIndexedAddressParts and getT2IndexedAddressParts, respectively, in a calls to: Offset = DAG.getConstant(-RHSC, RHS->getValueType(0)); ^^^^^ here! So you don't need...

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 those situations where I would assume it. For example, it does not use the...

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

----- Original Message ----- > From: "Dmitry Antipov" <antipov at dev.rtsoft.ru> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Renato Golin" <renato.golin at linaro.org>, llvmdev at cs.uiuc.edu > Sent: Thursday, April 4, 2013 3:22:05 AM > Subject: Is r174746 broken on ARM? > > Hello Hal, > > I have a strong suspicion

...ndexedStoreAction(ISD::PRE_INC, MVT::i8, Legal); setIndexedStoreAction(ISD::PRE_INC, MVT::i16, Legal); setIndexedStoreAction(ISD::PRE_INC, MVT::i32, Legal); setIndexedStoreAction(ISD::PRE_INC, MVT::i64, Legal); Then the DAGCombiner 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 c...

Hello Hal, I have a strong suspicion that your constant folding optimization introduced at r174746 is broken on ARM. There is a bug about it: http://llvm.org/bugs/show_bug.cgi?id=15581 There is no such issue with 3.2, and reverting r174746 on top of r178740 also fixes the problem. I'm trying to fix it myself, but still have no good ideas; so it would be great to have an advice from you.

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

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,