llvm dev - Mar 2017 - [inline-asm][asm-goto] Supporting "asm goto" in inline assembly

Linux kernel is using the “asm goto” feature, other projects probably use it as
well. I think it provides motivation to support it in LLVM.
Regarding the complexity, I believe there is some infrastructure that we can at
least partially reuse (the support for “indirectbr” instruction).

My focus is adding “asm goto” support, the other things are indeed completely
orthogonal and came up in bugs related to Bug
9295<https://bugs.llvm.org/show_bug.cgi?id=9295>.
The reason I mentioned them in this discussion is that they seem to require IR
change as well.
I thought that if we’re doing this IR change for “asm goto” it’s worth checking
if there is additional useful information we want to expose except the C labels
used by inline assembly.
If you prefer to separate the IR changes for “asm goto” and the IR changes that
will allow exposing defined symbols, then we can focus on the “asm goto” feature
alone.

Thanks,
Marina



From: Chandler Carruth [mailto:chandlerc at gmail.com]
Sent: Thursday, March 30, 2017 11:21
To: Yatsina, Marina <marina.yatsina at intel.com>; llvm-dev at
lists.llvm.org; rnk at google.com; jyknight at google.com; ehsan at mozilla.com;
rjmccall at apple.com; mehdi.amini at apple.com; chandlerc at gmail.com; matze
at braunis.de
Subject: Re: [llvm-dev] [inline-asm][asm-goto] Supporting "asm goto"
in inline assembly

On Wed, Mar 29, 2017 at 9:38 AM Yatsina, Marina via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Hi,

I wanted to revive this issue of supporting asm goto (Bug
9295<https://bugs.llvm.org/show_bug.cgi?id=9295>).

FWIW, my opinion is that the use cases don't really justify the complexity
this adds to the compiler. I feel like embedding inline assembly into normal C
control flow constructs and writing the entire thing directly give pretty
reasonable options.

But maybe others really see high-value reasons to add support for this... If
they do...

As was already proposed, the best way seems to be introducing new IR.
If we’re changing the IR, we should probably provide an infrastructure that
solves or at least enables future support for things like:

1.      MS-style inline asm jmps and goto (Bug
24529<https://bugs.llvm.org/show_bug.cgi?id=24529>)
I *strongly* agree with the 'WONTFIX' resolution here. More than
GCC's "asm goto", this feature seems much more harmful to the
compiler and much less well motivated.


2.      Analyzing symbols defined/references in the inline assembly (Bug
28970<https://bugs.llvm.org/show_bug.cgi?id=28970>), taking into account
module/file-scope inline assembly.
Unless we decide to address #1 in some way, this seems completely orthogonal to
"asm goto". While I'd love to see a good resolution to PR28970, I
don't think it makes sense to couple the two together. Among other things,
none of my concerns about "asm goto" apply to simply exposing the
symbols defined.


3.      Provide some information about the cost of the inline assembly? (I’m not
sure if we want to couple it with this issue and if the cost should be
represented in this new IR or some other way)
I suspect this too should be an orthogonal discussion.

I think we should expose a TTI-cost-analysis API and allow passing inline
assembly to it. Then targets can, if they choose, actually analyze the assembly
to compute a cost. But I don't think we need IR changes here and even if we
do, likely orthogonal ones to "asm goto".
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170330/97425d6b/attachment.html>

On Thu, Mar 30, 2017 at 02:44:32PM +0000, Yatsina, Marina via llvm-dev
wrote:
> Linux kernel is using the “asm goto” feature, other projects probably
> use it as well. I think it provides motivation to support it in LLVM.
I haven't seen anything in all of pkgsrc. Just as data point.

Joerg

Just responding to the motivation stuff as that remains an open question:

On Thu, Mar 30, 2017 at 4:44 PM Yatsina, Marina <marina.yatsina at
intel.com>
wrote:
> Linux kernel is using the “asm goto” feature,
>
But your original email indicated they have an alternative code path for
compilers that don't support it?

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.

> other projects probably use it as well.
>
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.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170330/25c527cd/attachment.html>

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).

GCC documentation describes their motivating example here:

https://gcc.gnu.org/onlinedocs/gcc-4.8.4/gcc/Extended-Asm.html



     #define TRACE1(NUM)                         \

       do {                                      \

         asm goto ("0: nop;"                     \

                   ".pushsection trace_table;"   \

                   ".long 0b, %l0;"              \

                   ".popsection"                 \

                   : : : : trace#NUM);           \

         if (0) { trace#NUM: trace(); }          \

       } while (0)

     #define TRACE  TRACE1(__COUNTER__)

In this example (which in fact inspired the asm goto feature) we want on rare
occasions to call the trace function; on other occasions we'd like to keep
the overhead to the absolute minimum. The normal code path consists of a single
nop instruction. However, we record the address of this nop together with the
address of a label that calls the trace function. This allows the nop
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 asm.
Here is the Linux kernel RFC which discusses the old C way of implementing it
and the performance issues that were noticed.
It also states some performance numbers of the old C code vs. the asm goto:
https://lwn.net/Articles/350714/



This LTTng (Linux Trace Toolkit Next Generation) presentation talks about using
this feature as a way of optimize static tracepoints (slides 3-4)
https://www.computer.org/cms/ComputingNow/HomePage/2011/0111/rW_SW_UsingTracing.pdf

This presentation also mentions that a lot of other Linux applications use this
tracing mechanism.

I believe we already have much of the infrastructure in place (using the
indirecbr instruction infrastructure).
We do need to make sure MachineBlockPlacement optimizes the fall through path to
make sure we can gain the performance for the nop patching.

Thanks,
Marina

From: Chandler Carruth [mailto:chandlerc at gmail.com]
Sent: Thursday, March 30, 2017 23:22
To: Yatsina, Marina <marina.yatsina at intel.com>; llvm-dev at
lists.llvm.org; rnk at google.com; jyknight at google.com; ehsan at mozilla.com;
rjmccall at apple.com; mehdi.amini at apple.com; matze at braunis.de; Tayree,
Coby <coby.tayree at intel.com>
Subject: Re: [llvm-dev] [inline-asm][asm-goto] Supporting "asm goto"
in inline assembly

Just responding to the motivation stuff as that remains an open question:

On Thu, Mar 30, 2017 at 4:44 PM Yatsina, Marina <marina.yatsina at
intel.com<mailto:marina.yatsina at intel.com>> wrote:
Linux kernel is using the “asm goto” feature,

But your original email indicated they have an alternative code path for
compilers that don't support it?

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.

other projects probably use it as well.

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.

-Chandler
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170404/9e4e52e6/attachment.html>