[LLVMdev] Post Increment Indirect Move Instructions

[Hal Finkel]

----- Original Message -----
> 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 i16 indirect load need to be converted to 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).

> 
> 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 am wrong). We are doing this
> transformation in the Lowering of the Loads and stores.

That's correct. You're situation seems to be slightly different from the case that the infrastructure normally handles. Nevertheless, it seems like you're trying to get some kind of interaction with an optimization pass. If so, what are you looking to achieve? In general, if you're looking to interact with the DAGCombine simplifications, then you should somehow transform your loads into POST_INC loads. You can also introduce target-specific DAGCombine code, or a MI-level peephole pass.

> 
> Does the Machine Instruction class provides any way to encode this
> information?

No, at the MI level, we can currently only encode that there is a constraint that some input operand must be the same as some output operand. For example, the PowerPC backend has a pre-increment store encoded like this:

def STDUX : XForm_8<31, 181, (outs ptr_rc_nor0:$ea_res), (ins g8rc:$rS, memrr:$dst),
                    "stdux $rS, $dst", LdStSTDU, []>,
                    RegConstraint<"$dst.ptrreg = $ea_res">, NoEncode<"$ea_res">;
}

def : Pat<(pre_store i64:$rS, iPTR:$ptrreg, iPTR:$ptroff),
          (STDUX $rS, $ptrreg, $ptroff)>;

Note that the instruction has a pseudo-output operand $ea_res which is constrained and not encoded. You are correct, however, that this does not encode any information on the relationship between the input and output value. That is done only at the SDAG level.

 -Hal

> 
> Thanks for your help.
> 
> Regards,
> Shashidhar
> 
> On Tuesday 01 October 2013 12:38 AM, Hal Finkel wrote:
> > ----- Original Message -----
> >> 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?
> > 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 post_store pattern.
> >
> >   -Hal
> >
> >> Thanks and regards,
> >> Shashidhar
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >>
> 
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory