<div dir="ltr">To try to rephrase, these are the transformations to and from MC in LLVM:<div>assembly -> MCInsts</div><div>MachineInstrs -> MCInsts<br></div><div>MCInsts -> object file<br></div><div>MCInsts -> assembly<br></div><div><br></div><div>It sounds you're having trouble translating from MachineInstrs to MCInsts, but printing assembly strings from MachineInstrs is easy for some reason.</div><div><br></div><div>I don't really see why we'd want to go back to the old way of printing assembly strings from the compiler, and then reparsing them, even if it were in-process. We did a lot of work to avoid that whole re-parsing step to save on compile time.</div><div><br></div><div>I don't fully understand the challenges your target presents, but I'm not convinced that they can't be overcome with some good engineering. Printing asm strings and building MCInsts seem like equivalently difficult problems that would leverage the same underlying logic.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 17, 2015 at 5:47 PM, Steve King <span dir="ltr"><<a href="mailto:steve@metrokings.com" target="_blank">steve@metrokings.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Short version: If the integrated assembler accepted assembly strings<br>
as input, more targets could take advantage of integrated assembly.<br>
<br>
The longer version:<br>
<br>
For a given assembly statement, my out-of-tree target has complex<br>
instruction selection logic -- more so than the in-tree targets.  This<br>
target uses variable length instructions and a laborious hierarchy of<br>
tblgen AsmOperands to do the job.  Assembly and disassembly with<br>
llvm-mc and llvm-objdump work fine.<br>
<br>
As a simplification, the compiler deals almost exclusively in pseudo<br>
instructions.  By x86 analogy, using pseudos to unfold a TEST32rm into<br>
MOV32rm + TEST32rr means I can skip the complex operand fitting effort<br>
needed to pick specific machine instructions.  There are many such<br>
examples where handling real instructions would become a gross<br>
overload.<br>
<br>
One drawback of this approach is that the integrated assembler<br>
receives only unexpanded pseudos as input, which fails.  So, my target<br>
must generate .s files and assemble as a separate step.<br>
<br>
If a target could pass an assembly string to the integrated assembler,<br>
the pseudo problem goes away. The string passed to the integrated<br>
assembler could come wrapped in a pseudo MCInst or whatever.  Support<br>
for asm string parsing already exists in every target, so this doesn't<br>
seem like much of a stretch.<br>
<br>
Thanks for any comments on this idea.<br>
<br>
Regards,<br>
-steve<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div><br></div>