search for: post_inc

...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). > >> I thin...

...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). > > I think...

...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 probably use the pos...

Hi all, This is version three of the patches I previously posted here: v1: https://lore.kernel.org/lkml/20191108170120.22331-1-will at kernel.org/ v2: https://lore.kernel.org/r/20200630173734.14057-1-will at kernel.org Changes since v2 include: * Actually add the barrier in READ_ONCE() for Alpha! * Implement Alpha's smp_load_acquire() using __READ_ONCE(), rather than the other

Hi everyone, This is the long-awaited version two of the patches I previously posted in November last year: https://lore.kernel.org/lkml/20191108170120.22331-1-will at kernel.org/ I ended up parking the series while the READ_ONCE() implementation was being overhauled, but with that merged during the recent merge window and LTO patches being posted again [1], it was time for a refresh. The

Hi everyone, This is the long-awaited version two of the patches I previously posted in November last year: https://lore.kernel.org/lkml/20191108170120.22331-1-will at kernel.org/ I ended up parking the series while the READ_ONCE() implementation was being overhauled, but with that merged during the recent merge window and LTO patches being posted again [1], it was time for a refresh. The

...> 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 probably use the pos...

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

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

...etReg() == DepReg) { >> + return false; >> + } >> + >> + if (QII->isPostIncrement(PacketMI)&& >> + PacketMI->getDesc().mayLoad()&& >> + GetPostIncrementOperand(PacketMI, QII).getReg() == DepReg) { >> + // if source is post_inc, or absolute-set addressing, >> + // it can not feed into new value store >> + // r3 = memw(r2++#4) >> + // memw(r30 + #-1404) = r2.new -> can not be new value store >> + // arch spec section: 5.4.2.1 >> + return false; >> + } >> + &gt...