<div dir="ltr">Here's my understanding of what I think happens today.<div><br></div><div>-For a very select few instructions if the AsmParser sees a repne/repe prefix it creates a special version of the instruction that has the REP bits set in TSFlags. For any other instruction it emits the repne/rep/repe as a separate MCInst.</div><div>-For the disassembler if it sees a repne/repe byte at the start that it doesn't think goes with an instruction it will emit a MCInst containing just the REP.</div><div>-If the disassembler encounters a repne/repe byte not at the start of the instruction that doesn't go with the instruction we drop it and don't print anything. The disassembler interface only allows us to return one instruction. So we can't return a separate repne/repe instruction and a real instruction from the same byte sequence. I don't believe the assembler can ever produce a byte sequence that hits this case, but that doesn't mean some binary couldn't contain that string of bytes created by hand. So this patch is trying to preserve the extra prefix information in the one MCInst we're allowed to emit. Maybe another option would be to allow creating multiple MCInsts from the disassembler?</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature">~Craig</div></div>
<br><div class="gmail_quote">On Tue, Sep 26, 2017 at 10:37 AM, Rafael Avila de Espindola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The question is why it is different for disassembler than for the<br>
assembler?<br>
<br>
How does the assembler handle trepne?<br>
<br>
Cheers,<br>
Rafael<br>
<div class="HOEnZb"><div class="h5"><br>
Andrew Tischenko <<a href="mailto:tishenandr@xenzu.com">tishenandr@xenzu.com</a>> writes:<br>
<br>
> It is not a simple flag, it's some data. And this data could be useful<br>
> for any other component because it's some opaque info which could be<br>
> send via MCInst from one low level target component to another one.<br>
> Without this (additional) data MCInst loosing (potentially very useful)<br>
> info about the given instruction.<br>
><br>
> Andrew<br>
><br>
> On <a href="tel:25.09.2017%2022" value="+12509201722">25.09.2017 22</a>:05, Rafael Avila de Espindola wrote:<br>
>> Having a flag field that is used only on disassembly seems wrong.<br>
>><br>
>> Don't we support parsing our own output? I don't see trepne in any .s<br>
>> test for example.<br>
>><br>
>> Cheers,<br>
>> Rafael<br>
>><br>
>> Craig Topper via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> writes:<br>
>><br>
>>> craig.topper added a comment.<br>
>>><br>
>>> I'm not sure I can approve growing the size of MCInst. Though I can't see anyway around it. @rafael what do you think?<br>
>>><br>
>>><br>
>>> <a href="https://reviews.llvm.org/D37262" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D37262</a><br>
</div></div></blockquote></div><br></div>