<div dir="ltr">FWIW, the bitwise representation is less of an issue as it preserves the an essential property <div>of an integer - that of being one integer :)</div><div><br></div><div>Since it's quite a basic assumption people make without noticing they do it, it's far less likely</div>
<div>to cause any problems down the pipe than a pair representation.</div><div><br></div><div>The difficulty is knowing at MachineOperand lowering whether an immediate should be encoded</div><div>straight or in the value + rot pair.</div>
<div><br></div><div>Regards,</div><div>Mihai</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 13, 2013 at 2:36 PM, Mihail Popa <span dir="ltr"><<a href="mailto:mihail.popa@gmail.com" target="_blank">mihail.popa@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Is there any proper documentation for what ComplexPatterns do and how they interact with<div>the rest of the descriptions in the td file? Surprisingly, Google is not my friend today.</div>
<div><br></div><div>
Specifically why do I get error in pattern definitions once I add MIOperandInfo? Ex:</div><div><div><br></div><div>/home/mihpop01/llvm/trunk/lib/Target/ARM/ARMInstrInfo.td:3227:1: error: In anonymous.377: Instruction 'SUBri' expects more operands than were provided.</div>
<div>def : ARMPat<(add GPR:$src, so_imm_neg:$imm),</div></div><div><br></div><div>Also why do I get error for move instruction definitions only? Eg:</div><div><br></div><div><div>/home/mihpop01/llvm/trunk/lib/Target/ARM/ARMInstrInfo.td:3523:1: error: In MVNi: Instruction 'MVNi' expects more operands than were provided.</div>
<div>def MVNi : AsI1<0b1111, (outs GPR:$Rd), (ins so_imm:$imm), DPFrm,</div><div>^</div></div><div><br></div><div>What I find bewildering is that the other instructions definitions are accepted. Is </div><div>there anything special about moves? </div>
<div><br></div><div>If you can point me to any documentation which explains these things satisfactorily, I'd be much in debt.</div><div><br></div><div>Leaving implementation details aside and if I my intuition serves me right, then the following should be true:</div>
<div><br></div><div>1. i can have the selector produce two int32 MachineOperands via a selection pattern</div><div>2. the two int32 MachineOperands will be automatically lowered to MCOperands</div><div>3. the instructions accepting this kind of operand will still have only one $imm in the syntax string</div>
<div>4. the custom parser will parse the string and generate to immediate MCOperands</div><div>5. all methods which manipulate operands of this type need to read TWO operands instead of one.</div><div>(which I have seen done before and I find rather peculiar -- it really only works when this operand is </div>
<div>the last one).</div><div><br></div><div>But here is the problem: since this kind of immediate may be affected by fixups, it will be potentially</div><div>modified outside the encoder/decoder/printer/render methods which are tied to the operand class.</div>
<div>Thus I actually need to know based on an opcode:</div><div><br></div><div>a. that an instruction even accepts am SOImm and not a normal imm</div><div>b. (ideally) which operand is the first of the two... now you may point out that modified immediates </div>
<div>come always last, but relying on that seems really dirty.</div><div><br></div><div>Regards,</div><div>Mihai</div><div><br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br>
<div class="gmail_quote">On Tue, Aug 13, 2013 at 2:02 PM, Tim Northover <span dir="ltr"><<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Mihai,<br>
<div><br>
On 13 August 2013 13:40, Mihail Popa <<a href="mailto:mihail.popa@gmail.com" target="_blank">mihail.popa@gmail.com</a>> wrote:<br>
>> Incidentally, adding an "MIOperandInfo = (ops i32imm:$value, i32imm:$rot)"<br>
>> would probably make the internal representation neatest here. by giving your<br>
>> MachineInstr two separate operands for the<br>
>> immediate value.<br>
><br>
> Not so sure how this can help with anything since the natural representation<br>
> of an integer is ... well, one integer.<br>
<br>
</div>But you've got the problem that there are multiple encodings for the<br>
integer 0 (for example). You could squash them into one MCOperand as<br>
(say) "BaseImm | (RotAmt << 8)", but splitting them into two<br>
MCOperands strikes me as more accurate.<br>
<div><br>
> I am not sure I understand how you could have the instruction selector<br>
> produce two operands instead of one.<br>
<br>
</div>That's what ComplexPatterns do, provided the extra operands are hidden<br>
in an MIOperandInfo. For example<br>
<br>
def so_imm : Operand<i32>, ComplexPattern<i32, 2, "SelectSOImm"> {<br>
let MIOperandInfo = (ops i32imm:$value, i32imm:$rot);<br>
[...]<br>
}<br>
<br>
lets you write patterns like "(set GPR:$Rd, (add GPR:$Rn,<br>
so_imm:$imm))". The function "SelectSOImm" would get called with two<br>
"SDValue &" operands that it's expected fill up based on its input<br>
node if it succeeds.<br>
<div><br>
> In addition there would still have to be a further lowering pass when the<br>
> MCOperand is generated.<br>
<br>
</div>That's all handled automatically, if I understand you correctly. Both<br>
the MachineInstr and the MCInst would have two immediate operands.<br>
<div><br>
> Speaking of which - looking at how MachineOperands are lowered to<br>
> MCOperands: how can I tell that a specific<br>
> MachineOperand::MO_Immediate will actually end up being an ARMSOImm? The<br>
> MCOperandInfo structures don't help.<br>
<br>
</div>I don't believe you can. Why do you think you need to?<br>
<br>
Cheers.<br>
<span><font color="#888888"><br>
Tim.<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>