<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
James Malloy added support for this recently.  I'm using it in a downstream back-end today, as are others.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
(Similarly, Daniel Sanders extended the FixedLenDecoderEmitter to support instruction words > 64 bits).<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
commit 60aadd19cbffc3793476a14d2e3529214119e2f5
<div>Author: James Molloy <jmolloy@google.com></div>
<div>Date:   Sun Sep 15 08:35:08 2019 +0000</div>
<div><br>
</div>
<div>    [CodeEmitter] Support instruction widths > 64 bits</div>
<div>    </div>
<div>    Some VLIW instruction sets are Very Long Indeed. Using uint64_t constricts the Inst encoding to 64 bits (naturally).</div>
<div>    </div>
<div>    This change switches CodeEmitter to a mode that uses APInts when Inst's bitwidth is > 64 bits (NFC for existing targets).</div>
<div>    </div>
<div>    When Inst.BitWidth > 64 the prototype changes to:</div>
<div>    </div>
<div>      void TargetMCCodeEmitter::getBinaryCodeForInstr(const MCInst &MI,</div>
<div>                                                      SmallVectorImpl<MCFixup> &Fixups,</div>
<div>                                                      APInt &Inst,</div>
<div>                                                      APInt &Scratch,</div>
<div>                                                      const MCSubtargetInfo &STI);</div>
<div>    </div>
<div>    The Inst parameter returns the encoded instruction, the Scratch parameter is used internally for manipulating operands and is exposed so that the underlying storage can be reused between calls to getBinaryCodeForInstr. The goal is to elide any APInt
 constructions that we can.</div>
<div>    </div>
<div>    Similarly the operand encoding prototype changes to:</div>
<div>    </div>
<div>      getMachineOpValue(const MCInst &MI, const MCOperand &MO, APInt &op, SmallVectorImpl<MCFixup> &Fixups, const MCSubtargetInfo &STI);</div>
<div>    </div>
<div>    That is, the operand is passed by reference as APInt rather than returned as uint64_t.</div>
<div>    </div>
<div>    To reiterate, this APInt mode is enabled only when Inst.BitWidth > 64, so this change is NFC for existing targets.</div>
<div>    </div>
<div>    llvm-svn: 371928</div>
<div><br>
</div>
<br>
<br>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> llvm-dev <llvm-dev-bounces@lists.llvm.org> on behalf of Paul C. Anagnostopoulos via llvm-dev <llvm-dev@lists.llvm.org><br>
<b>Sent:</b> Sunday, November 29, 2020 3:17 PM<br>
<b>To:</b> llvm-dev@lists.llvm.org <llvm-dev@lists.llvm.org><br>
<b>Subject:</b> [llvm-dev] TableGen machine code emitter backend</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">External email: Use caution opening links or attachments<br>
<br>
<br>
In my travels through the TableGen backends, I just learned that the machine code emitter can build instructions no longer than 8 bytes. Is there any interest in extending this to, say, 16 bytes?<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
llvm-dev@lists.llvm.org<br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div>
</span></font></div>
</body>
</html>