<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 Thomas,<div class=""><br class=""></div><div class="">The reason is simply because an implicit def of a virtual register doesn’t make sense in theory.</div><div class=""><br class=""></div><div class="">The rationale is let say that an instruction implicitly defines a virtual register. The implicit aspect of it means that this information cannot be “seen”. Thus, when we finally emit the instruction, there is nothing in the encoding or anywhere that is going to tell where the value has been physically defined.</div><div class=""><br class=""></div><div class="">The only way something is implicitly defined is when everybody knows where the value is going to end up and that’s only achievable in a physical register.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">-Quentin<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 18, 2019, at 6:21 PM, Thomas Lively 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=""><div dir="ltr" class="">Hi all,<div class=""><br class=""></div><div class="">I need to figure out why InstrEmitter::EmitMachineNode assumes that when the number of outputs of a MachineSDNode is greater than the number of defs in the corresponding MCInstrDesc, the outputs in the difference will be placed into physical registers as opposed to virtual registers.<br class=""></div><div class=""><br class=""></div><div class="">The specific line in question is:</div><div class=""> bool HasPhysRegOuts = NumResults > NumDefs && II.getImplicitDefs()!=nullptr;</div><div class=""><br class=""></div><div class="">Where NumResults is the number of outputs in the MachineSDNode and NumDefs comes from the MCInstrDesc and ultimately the TableGen definition of the instruction. I do not know why this assumption is made or what code depends on it, but it is over 12 years old: <a href="https://github.com/llvm/llvm-project/commit/c5549fc3a055710a3958a5b3164db3fa167c720c#diff-9dfdb934cb2b01ba001da4bbf3c5cb3cR632" class="">https://github.com/llvm/llvm-project/commit/c5549fc3a055710a3958a5b3164db3fa167c720c#diff-9dfdb934cb2b01ba001da4bbf3c5cb3cR632</a>. </div><div class=""><br class=""></div><div class="">The context for this question is that I am trying to implement an instruction for the WebAssembly backend that returns a variable number of operands. I am following the example of ARM's load multiple instructions, but this assertion in the instruction emitter is causing problems because WebAssembly, unlike ARM, does not use physical registers at all. Also, almost all WebAssembly instructions have an implicit def of the register that represents the argument stack, so II.getImplicitDefs() is necessarily non-null.</div><div class=""><br class=""></div><div class="">I am open to ideas about the best way forward. I am currently thinking that if this assumption is important for most targets, I might need to add a new bit to MCInstrDesc to disable this assumption.</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="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></div></body></html>