<div dir="auto">Hi,<div dir="auto">Really cool! I'm happy to help with the testing whenever useful.</div><div dir="auto"><br></div><div dir="auto">Is the kernel patch available? I'd like to try to compile the kernel as well.</div><div dir="auto"><br></div><div dir="auto">Thanks</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 23, 2019, 00:02 Craig Topper via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>Here's a quick update for those not watching the patch on llvm-commits. I've picked up the patch from Alexander Ivchenko.</div><div><br></div><div>LLVM patch here(same link as previously):<a href="https://reviews.llvm.org/D53765" style="font-family:Calibri,sans-serif;font-size:14.6667px" target="_blank" rel="noreferrer">https://reviews.llvm.org/D53765</a><br>Clang side patch has been posted to phab: <a href="https://reviews.llvm.org/D56571" target="_blank" rel="noreferrer">https://reviews.llvm.org/D56571</a></div><div><br></div><div>LLVM patch has been rebased after the TerminatorInst removal and the removal of CRTP from CallBase. This reduced some code in the CallBrInst as expected and simplified a few other places.</div><div><br></div><div>A few bugs found during testing have been fixed.</div><div><br></div><div>Nick Desaulniers from google has reported some success compiling, linking, and booting linux using clang with these patches and a special kernel patch.</div><div><br></div><div>I welcome any feedback on the patches. We're hoping to get this landed in trunk soon to make testing easier even if its not completely bug free.</div><div><br></div><div>~Craig</div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 9, 2019 at 3:22 PM Bill Wendling via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I wanted to check and see what the status of this is.</div><br><div class="gmail_quote"><div dir="ltr">On Sun, Nov 4, 2018 at 2:24 AM Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank" rel="noreferrer">chandlerc@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">(and FWIW, I'm currently trying to finish the patch that makes this a reality... mostly hard because it has to unwind a loooot of complexity we've built up due to not having this)</div><br><div class="gmail_quote"><div dir="ltr">On Sat, Nov 3, 2018 at 5:47 PM Jeremy Lakeman via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><a href="http://lists.llvm.org/pipermail/llvm-dev/2018-May/123407.html" target="_blank" rel="noreferrer">http://lists.llvm.org/pipermail/llvm-dev/2018-May/123407.html</a></div><div dir="ltr"><br></div><div>TLDR; CallInst & InvokeInst should share lots of code and would be useful to share a base type, compared to terminators that don't really share much code.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 3 November 2018 at 19:06, Bill Wendling via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">I've been out of the loop for awhile. Is there an email thread about the "removing terminators as a thing" concept?</div><div class="m_5986922238822113945gmail-m_-1585071736491405161gmail-m_755781929416222820m_-3130171238997892037HOEnZb"><div class="m_5986922238822113945gmail-m_-1585071736491405161gmail-m_755781929416222820m_-3130171238997892037h5"><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 31, 2018, 10:13 PM Chris Lattner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>FWIW, I’m generally supporting of this direction, and would love to see asm goto support.<div><br></div><div>Could you compare and contrast asmbr to a couple other options?</div><div><br></div><div> - There is an effort to eliminate "terminators as a thing”, that would allow merging call and invoke. How does asmbr intersect with that work, in the short and long term? If asmbr is a short term thing, is there a clean migration path?</div><div><br></div><div> - Have you thought about or scoped the idea of having an asm instruction that is not a call? In the shortest term, it could always be a terminator (similar to invoke) but as the call/invoke work comes together it could be relaxed to being a non-terminator when not an “asm goto”. The rationale for this approach (which I’m not particularly attached to, just want to see what other’s think about it) is that asms are pretty different in some ways from other instructions, and if you’re introducing a new instruction (asmbr) anyway, we might as well consider moving them away from call completely.</div><div><br></div><div>-Chris</div><div><br></div><div><br><div><br><blockquote type="cite"><div>On Oct 25, 2018, at 1:58 PM, Ivchenko, Alexander via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer noreferrer" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br><div><div 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;text-decoration:none"><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">There have been quite a few discussions around asm-goto support in Clang and LLVM.<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">After working with several members of our community, this is a proposal that, in our opinion, strikes a reasonable balance and finally addresses the lack of implementation.<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">Justification<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">-----------------<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">One of the main motivations for inline assembly support in the compiler comes from the need to directly access hardware-specific instructions either not explicitly representable by the higher-level languages or not supported by the compiler in any form. The latter includes the case of early stages of hardware development when having a full compiler/toolchain support is not feasible. Introducing the control flow capabilities of inline assembly into the compiler will reasonably expand the prototyping/experimenting opportunities for the developers.<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">Having this feature will also allow us to support the software that already uses asm-goto. E.g. Linux Kernel, for which (at least for x86) the asm-goto is a mandatory requirement for the compiler. The other way of looking on that is having the compatibility with GCC.<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">Current support for inline assembly in LLVM<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">-----------------<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">LLVM supports inline assembler (<a href="https://llvm.org/docs/LangRef.html#inline-assembler-expressions" style="color:rgb(149,79,114);text-decoration:underline" rel="noreferrer noreferrer" target="_blank">https://llvm.org/docs/LangRef.html#inline-assembler-expressions</a>) expression through the use of a special value – the asm expression.<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">An example inline assembler expression is:<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"> i32 (i32) asm "bswap $0", "=r,r"<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">Inline assembler expressions may only be used as the callee operand of a call or an invoke instruction. Thus, typically we have:<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"> %X = call i32 asm "bswap $0", "=r,r"(i32 %Y)<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">Labels in inline-assembly are already supported in LLVM, so the only problem is the control-flow:<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">The IR instruction for "asm-goto" must be represented via a terminator instruction in the basic block with specially denoted successor parameters, for this reason the "call" instruction is not suitable. "invoke" is a terminator, but a very specific one - there is a "normal" control flow successor and an "exceptional" one. The "exceptional" one is required to be a landing pad. On the contrary, "asm-goto" can support many output labels in addition to fall through one and those labels represent regular code, not landing pads.<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">Hence, there is a need for introducing a new IR instruction.<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">The callbr instruction<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">-----------------<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">Our proposed approach is to introduce a new IR instruction named callbr with the following syntax:<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"> callbr <return_type> <callee> (<argtype1> <arg1>, ...) to label %normal or jump [label %transfer1, label %transfer2...]<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">This syntax indicates that the callee may transfer the control flow to a “normal” successor (generally the fallthrough in the source language code), denoted by the label after the keyword “to”, or to any of the “exceptional” successors (which are expected to be normal basic blocks) denoted by labels in the "or jump" list.<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">The CallBrInst class implementing the instruction is a subclass of CallBase and is used as a terminator.<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">Support for asm-goto is implemented by using “void asm” as the callee expression:<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"> callbr void asm sideeffect <flags> "<asm string>", "<constraints>"(<argtype1> <arg1>, …, i8* blockaddress(<function>, %transfer1), i8* blockaddress(<function>, %transfer2), ...) to label %normal or jump [label %transfer1, label %transfer2...]<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">For example, the asm-goto call:<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"> int example1(…) {<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"> …<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"> asm goto("testl %0, %0; jne %l1;" :: "r"(cond)::label_true);<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"> …<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"> label_true:<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"> …<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"> }<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">is represented as:<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"> define i32 @example1(…) {<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"> …<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"> callbr void asm sideeffect "testl $0, $0; jne ${1:l}",<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"> "r,X,~{dirflag},~{fpsr},~{flags}"(i32 %5,<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"> i8* blockaddress(@example1, %label_true))<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"> to label %normal or jump [label %label_true]<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"> <span> </span><u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"> normal:<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"> …<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"> label_true:<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"> …<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"> }<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">The labels from the label list of an asm-goto statement are used by the inline asm as data arguments. To avoid errors in asm parsing and CFG recognition, the labels are passed as arguments to the inline asm using additional “X” input constraints and blockaddress statements while also being used directly as elements of the jump list.<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">Implementing the callbr instruction and asm-goto requires some adaptation of the existing passes:<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">* All passes that deal with the CFG must consider all potential successors of the callbr instruction to be possible. This means that no passes that simplify the CFG based on any assumptions can work with callbr<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">* Due to the way successor and predecessor detection works, some CFG simplifications such as trivial block elimination may be blocked if they would result in duplicate successors for the callbr instruction, as such duplicate successors are incorrectly processed in the IR and cannot be removed due to being used by the callee<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">* The indirectbr expansion pass may destroy blockaddress expressions if the basic blocks they reference are possible successors of an indirectbr. It may have to be reworked to support this new usage of the blockaddress expression<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">Some other notes on the instruction and asm-goto implementation:<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">* The special status of the “normal” destination label allows to specifically adjust its transition probability to make it likely to become a fallthrough successor<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">* While the initial implementation of asm-goto won’t allow outputs, the instruction’s syntax supports them in principle, so the support for this can be added at a later date<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">* The general syntax of the callbr instruction allows to use it to implement the control flow tracking for setjmp/longjmp, but that is beyond the scope of this RFC<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">I would like to kindly ask for your comments and thoughts on that. I will also submit the prototype patch implementing the proposal to phabricator.<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">And the most important part, we would like to say huge thanks to Chandler Carruth, Reid Kleckner, James Y Knight, Bill Wendling, Eric Christopher, Richard Smith, Matthias Braun, Nick Desaulniers and others who contributed to this RFC - without you it would not be possible.<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">Alexander Ivchenko, Mikhail Dvoretckii<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">Links<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">-----------------<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">[1] asm-goto feature request tracker (<a href="https://bugs.llvm.org/show_bug.cgi?id=9295" style="color:rgb(149,79,114);text-decoration:underline" rel="noreferrer noreferrer" target="_blank">https://bugs.llvm.org/show_bug.cgi?id=9295</a>)<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">[2] Discussion in llvm community about asm-goto (<a href="https://groups.google.com/forum/#!topic/llvm-dev/v9_oGrBeE9s" style="color:rgb(149,79,114);text-decoration:underline" rel="noreferrer noreferrer" target="_blank">https://groups.google.com/forum/#!topic/llvm-dev/v9_oGrBeE9s</a>)<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">[3] Recent discussion in LKML that resurrected the discussion (<a href="https://lkml.org/lkml/2018/2/13/1049" style="color:rgb(149,79,114);text-decoration:underline" rel="noreferrer noreferrer" target="_blank">https://lkml.org/lkml/2018/2/13/1049</a>)<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">[4] asm-goto was made mandatory for x86 in January of this year: (<a href="https://github.com/ClangBuiltLinux/linux/commit/e501ce957a786ecd076ea0cfb10b114e6e4d0f40" style="color:rgb(149,79,114);text-decoration:underline" rel="noreferrer noreferrer" target="_blank">https://github.com/ClangBuiltLinux/linux/commit/e501ce957a786ecd076ea0cfb10b114e6e4d0f40</a>)<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">[5] GCC documentation describes their motivating example here:<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">(<a href="https://gcc.gnu.org/onlinedocs/gcc-4.8.4/gcc/Extended-Asm.html" style="color:rgb(149,79,114);text-decoration:underline" rel="noreferrer noreferrer" target="_blank">https://gcc.gnu.org/onlinedocs/gcc-4.8.4/gcc/Extended-Asm.html</a>)<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">[6] Linux kernel RFC which discusses the old C way of implementing tracepoints and the performance issues that were noticed. It also states some performance numbers of the old C code vs. the asm goto (<a href="https://lwn.net/Articles/350714/" style="color:rgb(149,79,114);text-decoration:underline" rel="noreferrer noreferrer" target="_blank">https://lwn.net/Articles/350714/</a>)<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">[7] LTTng (Linux Trace Toolkit Next Generation) presentation talks about using asm-goto feature as a way of optimize static tracepoints (slides 3-4) (<a href="https://www.computer.org/cms/ComputingNow/HomePage/2011/0111/rW_SW_UsingTracing.pdf" style="color:rgb(149,79,114);text-decoration:underline" rel="noreferrer noreferrer" target="_blank">https://www.computer.org/cms/ComputingNow/HomePage/2011/0111/rW_SW_UsingTracing.pdf</a>)<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">[8] A link to the gcc thread introducing this feature (<a href="http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01556.htm" style="color:rgb(149,79,114);text-decoration:underline" rel="noreferrer noreferrer" target="_blank">http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01556.htm</a>)<u></u><u></u></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;text-decoration:none;float:none;display:inline">_______________________________________________</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;text-decoration:none"><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;text-decoration:none;float:none;display:inline">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;text-decoration:none"><a href="mailto:llvm-dev@lists.llvm.org" style="color:rgb(149,79,114);text-decoration:underline;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" rel="noreferrer noreferrer" target="_blank">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;text-decoration:none"><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" style="color:rgb(149,79,114);text-decoration:underline;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" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></div></blockquote></div><br></div></div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer noreferrer" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</div></div><br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</blockquote></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>