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

[Steve Montgomery via llvm-dev]

> On 2 Nov 2015, at 10:27, Martin J. O'Riordan <martin.oriordan at movidius.com> wrote:
> 
> Thanks Steve, I will try this out.  I hadn’t realised that TableGen was restricted to matching instructions with more than one output operand.  I’m assuming that this is only a limitation for inferring an instruction from the patterns, because it does seem to manage schedules okay.

I’m basing my statement on the material at the end of the “Selection DAG Select Phase” in “The LLVM Target-Independent Code Generator”, http://llvm.org/docs/CodeGenerator.html#selectiondag-select-phase. I’ve not actually checked TableGen though so can’t be 100% sure that the documentation is still in date.
 
> Curiously, my memory Reg32+Reg16 pattern is very similar to yours (the 16-bit offset is sign-extended though):
>  
> // Memory address: 32-bit base register + 16-bit offset register
> def ADDRrr : ComplexPattern<iPTR, 2, "SelectADDRrr", []>;
> def MEMrr : Operand<iPTR> {
>   let PrintMethod = "printMemOffsetOperand";
>   let MIOperandInfo = (ops RC32, RC16_l);
> }
>  
> but it is still happy to select for offset’s > 16-bits.  There is something I am just not yet getting right, but it looks like I am on the right track.

I believe that the MIOperandInfo will constrain the register class for your 16-bit offset operand to RC16_1 but in itself it won’t affect the matching of the operand. Your SelectADDRrr will need to contain code to match an i32 added to a sign-extended i16. If you’ve already done that, then I’m out of ideas, sorry.

Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151102/29ba5672/attachment.html>