Our Architecture has indirect move instruction which increments
pointer implicitly and the target only has i8 type values. So the
of i16 will be converted to two i8 target loads wherein after the
load instruction, the pointer to the first i8 address will
increment to point to the next i8 value. So the post increment nature
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
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
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
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.