<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">My two cents:</div><div class=""><br class=""></div><div class="">- I think inline assembly should work even if the compiler cannot parse the contents. This would rule out msvc inline assembly (or alternatively put all the parsing and interpretation burden on the frontend), but would work with gcc asm goto which specifies possible targets separately.</div><div class="">- Supporting control flow in inline assembly by allowing jumps out of an assembly block seems natural to me.</div><div class="">- Jumping into an inline assembly block seems like an unnecessary feature to me.</div><div class="">- To have this working in lib/CodeGen we would need an alternative opcode with the terminator flag set. (There should also be opportunities to remodel some instruction flags in the backend, to be part of the MachineInstr instead of the opcode, but that is an orthogonal discussion to this)</div><div class="">- I don't foresee big problems in CodeGen, we should take a look on how computed goto is implementation to find ways to reference arbitrary basic blocks.</div><div class="">- The register allocator fails when the terminator instruction also writes a register which is subsequently spilled (none of the existing targets does that, but you could specify this situation in inline assembly).</div><div class="">- I'd always prefer intrinsics over inline assembly. Hey, why don't we add a -Wassembly that warns on inline assembly usage and is enabled by default...</div><div class="">- I still think inline assembly is valuable for new architecture bringup/experimentation situations.</div><div class=""><br class=""></div><div class="">- Matthias</div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Apr 4, 2017, at 9:26 AM, Chandler Carruth 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" style="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;" class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Apr 4, 2017 at 6:07 AM Yatsina, Marina via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="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 lang="EN-US" link="blue" vlink="purple" class="gmail_msg"><div class="gmail_msg m_1313265924369501237WordSection1"><p class="MsoNormal gmail_msg"><span class="gmail_msg" style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);">Asm goto feature was introduces to GCC in order to optimize the support for tracepoints in Linux kernel (it can be used for other things that do nop patching).<u class="gmail_msg"></u><u class="gmail_msg"></u></span></p><p class="MsoNormal gmail_msg"><span class="gmail_msg" style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);"><u class="gmail_msg"></u> <u class="gmail_msg"></u></span></p><p class="MsoNormal gmail_msg"><span class="gmail_msg" style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);">GCC documentation describes their motivating example here:<u class="gmail_msg"></u><u class="gmail_msg"></u></span></p><pre class="gmail_msg"><span class="gmail_msg" style="color: rgb(31, 73, 125);"><br class="gmail_msg"></span><a href="https://gcc.gnu.org/onlinedocs/gcc-4.8.4/gcc/Extended-Asm.html" class="gmail_msg" target="_blank">https://gcc.gnu.org/onlinedocs/gcc-4.8.4/gcc/Extended-Asm.html</a><u class="gmail_msg"></u><u class="gmail_msg"></u></pre><pre class="gmail_msg"><u class="gmail_msg"></u> <u class="gmail_msg"></u></pre><pre class="gmail_msg"> #define TRACE1(NUM) \<u class="gmail_msg"></u><u class="gmail_msg"></u></pre><pre class="gmail_msg"> do { \<u class="gmail_msg"></u><u class="gmail_msg"></u></pre><pre class="gmail_msg"> asm goto ("0: nop;" \<u class="gmail_msg"></u><u class="gmail_msg"></u></pre><pre class="gmail_msg"> ".pushsection trace_table;" \<u class="gmail_msg"></u><u class="gmail_msg"></u></pre><pre class="gmail_msg"> ".long 0b, %l0;" \<u class="gmail_msg"></u><u class="gmail_msg"></u></pre><pre class="gmail_msg"> ".popsection" \<u class="gmail_msg"></u><u class="gmail_msg"></u></pre><pre class="gmail_msg"> : : : : trace#NUM); \<u class="gmail_msg"></u><u class="gmail_msg"></u></pre><pre class="gmail_msg"> if (0) { trace#NUM: trace(); } \<u class="gmail_msg"></u><u class="gmail_msg"></u></pre><pre class="gmail_msg"> } while (0)<u class="gmail_msg"></u><u class="gmail_msg"></u></pre><pre class="gmail_msg"> #define TRACE TRACE1(__COUNTER__)<u class="gmail_msg"></u><u class="gmail_msg"></u></pre><p class="gmail_msg m_1313265924369501237noindent">In this example (which in fact inspired the<span class="Apple-converted-space"> </span><code class="gmail_msg"><span class="gmail_msg" style="font-size: 10pt;">asm goto</span></code><span class="Apple-converted-space"> </span>feature) we want on rare occasions to call the<span class="Apple-converted-space"> </span><code class="gmail_msg"><span class="gmail_msg" style="font-size: 10pt;">trace</span></code><span class="Apple-converted-space"> </span>function; on other occasions we'd like to keep the overhead to the absolute minimum. The normal code path consists of a single<span class="Apple-converted-space"> </span><code class="gmail_msg"><span class="gmail_msg" style="font-size: 10pt;">nop</span></code><span class="Apple-converted-space"> </span>instruction. However, we record the address of this<span class="Apple-converted-space"> </span><code class="gmail_msg"><span class="gmail_msg" style="font-size: 10pt;">nop</span></code><span class="Apple-converted-space"> </span>together with the address of a label that calls the<span class="Apple-converted-space"> </span><code class="gmail_msg"><span class="gmail_msg" style="font-size: 10pt;">trace</span></code>function. This allows the<span class="Apple-converted-space"> </span><code class="gmail_msg"><span class="gmail_msg" style="font-size: 10pt;">nop</span></code><span class="Apple-converted-space"> </span>instruction to be patched at run time to be an unconditional branch to the stored label. It is assumed that an optimizing compiler moves the labeled block out of line, to optimize the fall through path from the<span class="Apple-converted-space"> </span><code class="gmail_msg"><span class="gmail_msg" style="font-size: 10pt;">asm</span></code>.<span class="Apple-converted-space"> </span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span class="gmail_msg" style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);">Here is the Linux kernel RFC which discusses the old C way of implementing it and the performance issues that were noticed.<u class="gmail_msg"></u><u class="gmail_msg"></u></span></p><p class="MsoNormal gmail_msg"><span class="gmail_msg" style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);">It also states some performance numbers of the old C code vs. the asm goto:<u class="gmail_msg"></u><u class="gmail_msg"></u></span></p><p class="MsoNormal gmail_msg"><span class="gmail_msg" style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);"><a href="https://lwn.net/Articles/350714/" class="gmail_msg" target="_blank">https://lwn.net/Articles/350714/</a><u class="gmail_msg"></u><u class="gmail_msg"></u></span></p><pre class="gmail_msg"><span class="gmail_msg" style="color: rgb(31, 73, 125);"><u class="gmail_msg"></u> <u class="gmail_msg"></u></span></pre><pre class="gmail_msg"><span class="gmail_msg" style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);">This LTTng (Linux Trace Toolkit Next Generation) presentation talks about using this feature as a way of optimize static tracepoints (slides 3-4)</span><span class="gmail_msg" style="color: rgb(31, 73, 125);"><u class="gmail_msg"></u><u class="gmail_msg"></u></span></pre><p class="MsoNormal gmail_msg"><span class="gmail_msg" style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);"><a href="https://www.computer.org/cms/ComputingNow/HomePage/2011/0111/rW_SW_UsingTracing.pdf" class="gmail_msg" target="_blank">https://www.computer.org/cms/ComputingNow/HomePage/2011/0111/rW_SW_UsingTracing.pdf</a><u class="gmail_msg"></u><u class="gmail_msg"></u></span></p><pre class="gmail_msg"><span class="gmail_msg" style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);">This presentation also mentions that a lot of other Linux applications use this tracing mechanism.</span></pre></div></div></blockquote><div class="">Thanks, this is exactly the kind of discussion that I think will help make progress here.</div><div class=""><br class=""></div><div class="">I think this feature makes a lot of sense and is a really nice feature. However, I think implementing it with inline assembly imposes a lot of really unfortunate constraints on compilation -- it requires asm goto, pushsection and popsection, etc.</div><div class=""><br class=""></div><div class="">I would much rather provide a much more direct way to represent a patchable nop and the addresses of label within a function. For example, I could imagine something like:</div><div class=""><br class=""></div><div class="">```</div><div class=""> if (0) { trace_call: /* code to call the trace function */ }</div><div class=""> patch: __builtin_patchable_nop()</div><div class=""> __builtin_save_labels(trace_call, patch)</div><div class="">```</div><div class=""><br class=""></div><div class="">But someone can probably design a much better way to represent this in Clang. The advantages I see here (admittedly, mostly for the implementation in Clang and LLVM):</div><div class=""><br class=""></div><div class="">1) It allows Clang and LLVM to model this with running an assembler over anything.</div><div class="">2) It doesn't require new terminators in LLVM's IR</div><div class="">3) We already have intrinsics in LLVM's IR that could easily be extended to produce a nop.</div><div class="">4) It would be portable -- each backend could select an appropriate sized nop to patch a jump into</div><div class=""><br class=""></div><div class="">Would this make sense?</div><div class=""> </div><blockquote class="gmail_quote" style="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 lang="EN-US" link="blue" vlink="purple" class="gmail_msg"><div class="gmail_msg m_1313265924369501237WordSection1"><pre class="gmail_msg"><span class="gmail_msg" style="color: rgb(31, 73, 125);"><u class="gmail_msg"></u><u class="gmail_msg"></u></span></pre><p class="MsoNormal gmail_msg"><a name="m_1313265924369501237__MailEndCompose" class="gmail_msg"><span class="gmail_msg" style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);"><u class="gmail_msg"></u> <u class="gmail_msg"></u></span></a></p><p class="MsoNormal gmail_msg"><span class="gmail_msg" style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);">I believe we already have much of the infrastructure in place (using the indirecbr instruction infrastructure).<u class="gmail_msg"></u><u class="gmail_msg"></u></span></p><p class="MsoNormal gmail_msg"><span class="gmail_msg" style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);">We do need to make sure MachineBlockPlacement optimizes the fall through path to make sure we can gain the performance for the nop patching.<u class="gmail_msg"></u><u class="gmail_msg"></u></span></p><p class="MsoNormal gmail_msg"><span class="gmail_msg" style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);"><u class="gmail_msg"></u> <u class="gmail_msg"></u></span></p><p class="MsoNormal gmail_msg"><span class="gmail_msg" style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);">Thanks,<u class="gmail_msg"></u><u class="gmail_msg"></u></span></p><p class="MsoNormal gmail_msg"><span class="gmail_msg" style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);">Marina<u class="gmail_msg"></u><u class="gmail_msg"></u></span></p><p class="MsoNormal gmail_msg"><span class="gmail_msg" style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);"><u class="gmail_msg"></u> <u class="gmail_msg"></u></span></p><p class="MsoNormal gmail_msg"><b class="gmail_msg"><span class="gmail_msg" style="font-size: 11pt; font-family: Calibri, sans-serif;">From:</span></b><span class="gmail_msg" style="font-size: 11pt; font-family: Calibri, sans-serif;"><span class="Apple-converted-space"> </span>Chandler Carruth [mailto:<a href="mailto:chandlerc@gmail.com" class="gmail_msg" target="_blank">chandlerc@gmail.com</a>]<span class="Apple-converted-space"> </span><br class="gmail_msg"><b class="gmail_msg">Sent:</b><span class="Apple-converted-space"> </span>Thursday, March 30, 2017 23:22<br class="gmail_msg"><b class="gmail_msg">To:</b><span class="Apple-converted-space"> </span>Yatsina, Marina <<a href="mailto:marina.yatsina@intel.com" class="gmail_msg" target="_blank">marina.yatsina@intel.com</a>>;<span class="Apple-converted-space"> </span><a href="mailto:llvm-dev@lists.llvm.org" class="gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a>;<span class="Apple-converted-space"> </span><a href="mailto:rnk@google.com" class="gmail_msg" target="_blank">rnk@google.com</a>;<span class="Apple-converted-space"> </span><a href="mailto:jyknight@google.com" class="gmail_msg" target="_blank">jyknight@google.com</a>;<span class="Apple-converted-space"> </span><a href="mailto:ehsan@mozilla.com" class="gmail_msg" target="_blank">ehsan@mozilla.com</a>;<span class="Apple-converted-space"> </span><a href="mailto:rjmccall@apple.com" class="gmail_msg" target="_blank">rjmccall@apple.com</a>;<span class="Apple-converted-space"> </span><a href="mailto:mehdi.amini@apple.com" class="gmail_msg" target="_blank">mehdi.amini@apple.com</a>;<span class="Apple-converted-space"> </span><a href="mailto:matze@braunis.de" class="gmail_msg" target="_blank">matze@braunis.de</a>; Tayree, Coby <<a href="mailto:coby.tayree@intel.com" class="gmail_msg" target="_blank">coby.tayree@intel.com</a>></span></p></div></div><div lang="EN-US" link="blue" vlink="purple" class="gmail_msg"><div class="gmail_msg m_1313265924369501237WordSection1"><p class="MsoNormal gmail_msg"><span class="gmail_msg" style="font-size: 11pt; font-family: Calibri, sans-serif;"><br class="gmail_msg"><b class="gmail_msg">Subject:</b><span class="Apple-converted-space"> </span>Re: [llvm-dev] [inline-asm][asm-goto] Supporting "asm goto" in inline assembly<u class="gmail_msg"></u><u class="gmail_msg"></u></span></p></div></div><div lang="EN-US" link="blue" vlink="purple" class="gmail_msg"><div class="gmail_msg m_1313265924369501237WordSection1"><div class=""><span class="gmail_msg" style="font-size: 11pt; font-family: Calibri, sans-serif;"></span><br class="webkit-block-placeholder"></div><p class="MsoNormal gmail_msg"><u class="gmail_msg"></u> <u class="gmail_msg"></u></p><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg">Just responding to the motivation stuff as that remains an open question:<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div></div></div></div></div><div lang="EN-US" link="blue" vlink="purple" class="gmail_msg"><div class="gmail_msg m_1313265924369501237WordSection1"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg"><u class="gmail_msg"></u> <u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg">On Thu, Mar 30, 2017 at 4:44 PM Yatsina, Marina <<a href="mailto:marina.yatsina@intel.com" class="gmail_msg" target="_blank">marina.yatsina@intel.com</a>> wrote:<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><blockquote class="gmail_msg" style="border-style: none solid none none; border-right-width: 1pt; border-right-color: rgb(204, 204, 204); padding: 0cm; margin: 5pt 0cm 5pt 4.8pt;"><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg"><span class="gmail_msg m_1313265924369501237gmailmsg"><span class="gmail_msg" style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);">Linux kernel is using the “asm goto” feature,</span></span><u class="gmail_msg"></u><u class="gmail_msg"></u></p></div></div></blockquote><div class="gmail_msg"><p class="MsoNormal gmail_msg"><u class="gmail_msg"></u> <u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg">But your original email indicated they have an alternative code path for compilers that don't support it?<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg"><u class="gmail_msg"></u> <u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg">What might be compelling would be if there are serious performance problems when using the other code path that cannot be addressed by less invasive (and more general) improvements to LLVM. If this is the *only* way to get comparable performance from the Linux Kernel, then I think that might be an interesting discussion. But it would take a very careful and detailed analysis of why IMO.<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg"> <u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><blockquote class="gmail_msg" style="border-style: none solid none none; border-right-width: 1pt; border-right-color: rgb(204, 204, 204); padding: 0cm; margin: 5pt 0cm 5pt 4.8pt;"><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg"><span class="gmail_msg m_1313265924369501237gmailmsg"><span class="gmail_msg" style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);">other projects probably use it as well.</span></span><u class="gmail_msg"></u><u class="gmail_msg"></u></p></div></div></blockquote><div class="gmail_msg"><p class="MsoNormal gmail_msg"><u class="gmail_msg"></u> <u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg">This is entirely possible, but I'd like to understand which projects and why they use it rather than any of the alternatives before we impose the implementation complexity on LLVM. At least that's my two cents.<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg"><u class="gmail_msg"></u> <u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg">-Chandler<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div></div></div></div></div><div lang="EN-US" link="blue" vlink="purple" class="gmail_msg"><div class="gmail_msg m_1313265924369501237WordSection1"><div class="gmail_msg"><div class="gmail_msg"></div></div></div><p class="gmail_msg">---------------------------------------------------------------------<br class="gmail_msg">Intel Israel (74) Limited</p></div><div lang="EN-US" link="blue" vlink="purple" class="gmail_msg"><p class="gmail_msg">This e-mail and any attachments may contain confidential material for<br class="gmail_msg">the sole use of the intended recipient(s). Any review or distribution<br class="gmail_msg">by others is strictly prohibited. If you are not the intended<br class="gmail_msg">recipient, please contact the sender and delete all copies.</p></div><div lang="EN-US" link="blue" vlink="purple" class="gmail_msg"></div>_______________________________________________<br class="gmail_msg">LLVM Developers mailing list<br class="gmail_msg"><a href="mailto:llvm-dev@lists.llvm.org" class="gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a><br class="gmail_msg"><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="gmail_msg"></blockquote></div></div><span style="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; float: none; display: inline !important;" class="">_______________________________________________</span><br style="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;" class=""><span style="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; float: none; display: inline !important;" class="">LLVM Developers mailing list</span><br style="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;" class=""><a href="mailto:llvm-dev@lists.llvm.org" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">llvm-dev@lists.llvm.org</a><br style="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;" class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></div></blockquote></div><br class=""></body></html>