<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px">> Incidentally, adding an "MIOperandInfo = (ops i32imm:$value, i32imm:$rot)" would probably make the internal representation neatest here. by giving your MachineInstr two separate operands for the</span><div>
<span style="font-family:arial,sans-serif;font-size:13px">> immediate value.</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Not so sure how this can help with anything since the natural representation of an integer is ... well, one integer.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">I am not sure I understand how you could have the instruction selector produce two operands instead of one. </span></div><div><font face="arial, sans-serif">In addition there would still have to be a further lowering pass when the MCOperand is generated.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Speaking of which - looking at how MachineOperands are lowered to MCOperands: how can I tell that a specific</font></div><div><font face="arial, sans-serif">MachineOperand::MO_Immediate will actually end up being an ARMSOImm? The MCOperandInfo structures don't help.</font></div>
<div><font face="arial, sans-serif">The operand type is only set for the out-of-the-box types, not for the custom types. Any ideas how I can detect a particular</font></div><div><font face="arial, sans-serif">operand of a particular instruction is of a particular operand class? (without dumb-coding it, of course).</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Regards,</font></div><div><font face="arial, sans-serif">Mihai</font></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Fri, Aug 9, 2013 at 1:42 PM, Tim Northover <span dir="ltr"><<a href="mailto:tnorthover@apple.com" target="_blank">tnorthover@apple.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 class="im"><br>
> For solution 1, the blocking issue is the parser recognizing comma as a operand separator<br>
> and not matching patterns and assembly strings of different arity.<br>
<br>
</div>I think if you give your so_imm a ParserMethod then it short-circuits the normal comma-spotting, and it can eat as much of the string as it likes. This is how the addresses are matched, for example: even though "[r0, #3]" has a comma in it, the generic code doesn't see it.<br>

<br>
Incidentally, adding an "MIOperandInfo = (ops i32imm:$value, i32imm:$rot)" would probably make the internal representation neatest here. by giving your MachineInstr two separate operands for the immediate value.<br>

<br>
Because the two operands would be hidden behind the single so_imm it should be reasonably easy for a ComplexPattern to match them still.<br>
<div class="im"><br>
> For solution 2, the blocking issue is the selection patterns. Basically I'd have to have a separate<br>
> set on instructions for selection only, which makes the whole effort futile.<br>
<br>
</div>Yes, I think that goes wrong rather quickly. I can't think of a sensible way to match those instructions.<br>
<br>
Cheers.<br>
<span class="HOEnZb"><font color="#888888"><br>
Tim.<br>
</font></span></blockquote></div><br></div></div>