<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="">It’s not necessary to use virtual registers or stack frame management to use MI. The point of MI is to have a common interface to LLVM backend APIs so you can query the scheduling model, register usage, a variety of TTI/STI information, analyze control flow, and analyze the call graph.<div class=""><br class=""></div><div class="">Why would you ever want to duplicate all of MI’s goodness rather than using it directly?</div><div class=""><br class=""></div><div class="">I was under the impression that MC -> MI has been useful in the past and that it’s something we would want to support long term.<br class=""><div class=""><br class=""></div><div class="">-Andy<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 4, 2018, at 12:57 PM, Matthias Braun <<a href="mailto:matze@braunis.de" class="">matze@braunis.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">I haven’t actually worked on analyzing assembler so take this with a grain of salt/as a less informed opinion:</div><div class=""><br class=""></div><div class="">But I think MachineInstrs wouldn’t bring much of a benefit over MC here: MI is designed for lowering of a higher level IR towards a machine representation; that is a different goal and comes with various things (pseudo instructions, virtual register management, stack frame management, etc.) that don’t help for this use case and rather have the potential to be in the way...</div><div class=""><br class=""></div><div class="">I’d rather work towards remodeling the code/datastructures to make reuse in llvm-mca simpler where it makes sense.</div><div class=""><br class=""></div><div class="">- Matthias<br class=""><div class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 2, 2018, at 9:33 AM, Andrew Trick via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">+Ahmed<br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Mar 2, 2018, at 6:42 AM, Andrea Di Biagio <<a href="mailto:andrea.dibiagio@gmail.com" class="">andrea.dibiagio@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote class="gmail_quote" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word; line-break: after-white-space;" class=""><div class="">There are a number of people on llvm-dev who can explain better than I how to decompile into MachineInstrs. I’m not totally opposed to checking in something that works with MCInstr, but this does run strongly contrary to the design of LLVM’s subtarget support.</div></div></blockquote><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class=""></div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">That would be great! I would be very happy if somebody suggests how to do it (or does it for me :-)).<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">I know that’s it’s been done before, it’s an extremely useful technique, and work in that direction should be strongly encouraged. I don’t know the current state of in-tree support.</div><div class=""><br class=""></div><div class="">Ahmed?</div><br class=""><blockquote type="cite" class=""><div class=""><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">Do you think the current design (modulo the changes suggested in the review) would be acceptable to start?</div></div></blockquote></div><br class=""><div class="">I’ll let others review the patch. The fact that you have collaborators in the community is good enough for me.</div><div class=""><br class=""></div><div class="">-Andy</div></div>_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class=""></div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></div></div></body></html>