[llvm-dev] Questions about load/store incrementing address modes

[Martin J. O'Riordan via llvm-dev]

I have a rudimentary implementation for load and store instructions, where
the memory address operand is automatically post-incremented when the load
or store instruction is issued.  However, this is currently coded using
custom lowering, and explicit pattern matching in the 'ISelDAGtoDAG'
implementation.  But it seems to me that I ought to be able to achieve this
exclusively using TableGen with minimal custom C++ code, but I can't quite
get the patterns to work to achieve this.

 

I have two types of post-increment:

 

1.      increment by an implied constant which is the size of the object
being loaded or stored

2.      increment by the value contained in another register

 

It should be possible to do these with the same underlying pattern, but
providing a DAG fragment like '(i32 2)' for an 'i16' load explicitly in the
TableGen specialisation for the first form, and the actual register chain
for the second.

 

But I don't seem to be quite get it to work, and in some cases the patterns
I have attempted have crashed TableGen itself L  The incrementing store sort
of works, but the incrementing load doesn't (at least not using TableGen
alone).

 

 

The other form of addressing mode is where the address is a "base" plus
signed "offset" register.  My patterns for this work okay, but I have a
limitation.  The "offset" register is 16-bits, and in particular, it is the
low-order 16-bits of a 32-bit actual register.  But even though I have
explicitly stated in TableGen that the offset register is 16-bits and stated
the appropriate register class, the code-generation still uses the
instructions "as if" the offset register is 32-bits.

 

Memory addresses in this architecture are 32-bits.

 

Has anybody solved similar problems, and have advice or examples of how to
do this?  Or is simply something that TableGen descriptions cannot
completely describe?  I have looked at the other targets for inspiration,
but they don't quite seem to do what I need.

 

Thanks,

 

            Martin O'Riordan - Movidius Ltd.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151030/d94200f1/attachment-0001.html>