<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi All,<div class=""><br class=""></div><div class="">Happy New Year!</div><div class=""><br class=""></div><div class="">This is another update on the M68k backend.</div><div class=""><br class=""></div><div class="">Currently we still have 3 patches to review:</div><div class="">1. (1/8) TableGen changes <a href="https://reviews.llvm.org/D88385" class="">https://reviews.llvm.org/D88385</a> </div><div class="">2. (4/8) MC layer changes <a href="https://reviews.llvm.org/D88390" class="">https://reviews.llvm.org/D88390</a> </div><div class="">3. (5/8) Target Lowering <a href="https://reviews.llvm.org/D88391" class="">https://reviews.llvm.org/D88391</a> </div><div class=""><br class=""></div><div class="">4th (D88390) and 5th (D88391) patches only have minor formatting issues. </div><div class=""><br class=""></div><div class="">The biggest challenge now is in the first patch, D88385. Currently the patch proposed to add a new TableGen backend (CodeBeads) to generate auxiliary data structures for variable length encoding as well as complex addressing mode encodings. This is equivalent to X86’s usage of `MCInstrDesc::TSFlags` to carry their instruction encoding. However, TSFlags only has 64 bits, where M68k’s current design needs at least 24 bytes to encode all the instructions. While we might able to find an optimal way to fit M68k’s info into 64 bits in the future, the refactoring efforts to do it now is huge, especially on changing instructions definitions in TG files.</div><div class=""><br class=""></div><div class="">Jessica, who is listed in the blocker list of this patch, raised concerns about the necessity of this specialized TG backend, and proposed to re-use X86’s way to handle this problem. That is, put the M68k’s encoding info into MCInstrDesc with modifications in the InstrInfoEmitter TG backend.</div><div class=""><br class=""></div><div class="">Simon thought special handling in the InstrInfoEmitter/MCInstrDesc for M68k doesn’t have a huge difference with adding a specialized CodeBeads backend like the patch is doing now.</div><div class=""><br class=""></div><div class="">Renado preferred to keep the CodeBeads backend since it works well for M68k and later refactoring, if there is any, will probably only affect M68k. He also thought “where” to put this implementation - whether a TableGen or MCInstrDesc change - should come before asking “why” doing this change.</div><div class=""><br class=""></div><div class="">Personally, I also prefer to keep the current CodeBeads implementation and optimize it in the future. Since:</div><div class="">1. CodeBeads is an optional TG backend. It will not affect any existing Target. </div><div class="">2. As mentioned earlier, it works well on M68k now. And if there is any changes on it or even removal on this TG backend in the future, the refactoring cost is pretty low.</div><div class="">3. We don’t have many resources to conduct large scale fixes in a short time (<span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">the longer this patch series diverged from upstream, the higher the rebasing cost for other parts of M68k backend</span>) on this issue right now.</div><div class=""><br class=""></div><div class="">I would happy to hear if there is any suggestion on solving this challenge.</div><div class=""><br class=""></div><div class="">Thank you for the all the reviewing efforts!</div><div class=""><br class=""></div><div class="">Best,</div><div class="">-Min</div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Dec 17, 2020, at 11:42 PM, John Paul Adrian Glaubitz <<a href="mailto:glaubitz@physik.fu-berlin.de" class="">glaubitz@physik.fu-berlin.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi Min!<br class=""><br class="">On 12/18/20 1:21 AM, Min-Yih Hsu wrote:<br class=""><blockquote type="cite" class="">Another update on this topic: Currently three patches have been approved, thanks for all reviewers’ time and efforts :-)<br class=""></blockquote><br class="">I've read the reviews. Awesome progress.<br class=""><br class=""><blockquote type="cite" class="">Here are the remaining patches:<br class=""> - Patch 1/8 D88385: Got one LGTM, however I believe Jessica Clarke (jrtc27) (CC-ed here) is listed as blocker.<br class=""></blockquote> Does anyone here know the best way to contact Jessica? Since the patch has been blocked for quite a long time<br class=""> and pinging @jrtc27 on Phab didn’t seem to work<br class=""><br class="">I pinged jrtc27 on IRC (OFTC) and will keep pinging until we get an answer.<br class=""><br class=""><blockquote type="cite" class=""> - Patch 3/8 D88389 (Basic .td files)<br class=""> - Patch 4/8 D88390 (MC layer)<br class=""> - Patch 5/8 D88391 (Target lowering)<br class=""> - Patch 6/8 D88392 (IR Tests)<br class=""><br class="">Except Patch 6, which only has minor formatting issues to fix, I didn’t see any major<br class="">objections or concerns on other patches at this time point.<br class=""></blockquote><br class="">Sounds great.<br class=""><br class=""><blockquote type="cite" class="">In addition to the patch review, tomorrow Dec 18th 19:00 CET (10:00 AM PST), Nick Desaulniers<br class="">is going to give a talk on compiling Linux Kernel for M68k using LLVM.<br class="">Please checkout <a href="http://m68k.info/" class="">http://m68k.info/</a> <<a href="http://m68k.info/" class="">http://m68k.info/</a>> for more info about the live stream<br class=""></blockquote><br class="">Yep. I'm very exciting for this talk! And we're planning to put it on Youtube later.<br class=""><br class="">Adrian<br class=""><br class="">-- <br class=""> .''`. John Paul Adrian Glaubitz<br class="">: :' : Debian Developer - <a href="mailto:glaubitz@debian.org" class="">glaubitz@debian.org</a><br class="">`. `' Freie Universitaet Berlin - <a href="mailto:glaubitz@physik.fu-berlin.de" class="">glaubitz@physik.fu-berlin.de</a><br class=""> `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913<br class=""><br class=""></div></div></blockquote></div><br class=""></div></body></html>