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

Hi,

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

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.

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)

This new IR should contain:

1.      A list of symbols referenced by the inline assembly

a.      Should we try to provide better analysis of how we use these symbols
(e.g. in jmp instructions, in call instructions)? Can it help us do some error
checking?

2.      A list of symbols defines by the inline assembly

a.      Should we provide additional information about how symbols defined (e.g.
which symbols defined as globals)?.

At a later stage we also need to discuss other aspects of this new instruction
(e.g. it being a block terminator and other behaviors we might want to be
affected by it).
Any other thoughts and ideas we want to include in this change that I'm
missing?

Thanks,
Marina
---------------------------------------------------------------------
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/20170329/461db485/attachment-0001.html>

On Wed, Mar 29, 2017 at 9:38 AM Yatsina, Marina via llvm-dev <
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".
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170330/885a8b6f/attachment.html>

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>

Hi Marina,

As you've highlighted, LLVM's support for inline assembly could
definitely
use work. It is not a well-loved area of the compiler. =/ These are some of
my thoughts on what we could do.

I'd prefer to not support jumps into and out of MS inline asm blobs. I
sketched out a design for doing it in http://llvm.org/pr24529#c4, but it
creates more LLVM IR basic blocks that have no valid insertion point. I'd
like to move away from that, not towards it. MSVC doesn't even support
inline asm on non-x86, so over time there will be less demand for this
esoteric feature, not more.

I actually think supporting a terminator asm instruction for "asm
goto"
wouldn't be that expensive. We already have terminators like indirectbr and
catchswitch that create edges that can't be split. I suspect we will want
to add more to support parallel IR. Adding one for "asm goto"
doesn't seem
that bad, but I'm not convinced it's worth it.

Digging the symbol uses out of inline asm and the symbol definitions out of
module inline asm seems totally reasonable. Adding this to the IR
representation seems nice.

Improving our cost estimates with the help of MC would also be nice.

Reid

On Wed, Mar 29, 2017 at 12:37 AM, Yatsina, Marina <marina.yatsina at
intel.com>
wrote:
> Hi,
>
>
>
> I wanted to revive this issue of supporting asm goto (*Bug 9295*
> <https://bugs.llvm.org/show_bug.cgi?id=9295>).
>
> 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>)
>
> 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.
>
> 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)
>
>
>
> This new IR should contain:
>
> 1.      A list of symbols referenced by the inline assembly
>
> a.      Should we try to provide better analysis of how we use these
> symbols (e.g. in jmp instructions, in call instructions)? Can it help us do
> some error checking?
>
> 2.      A list of symbols defines by the inline assembly
>
> a.      Should we provide additional information about how symbols
> defined (e.g. which symbols defined as globals)?.
>
>
>
> At a later stage we also need to discuss other aspects of this new
> instruction (e.g. it being a block terminator and other behaviors we might
> want to be affected by it).
>
> Any other thoughts and ideas we want to include in this change that I’m
> missing?
>
>
>
> Thanks,
>
> Marina
>
> ---------------------------------------------------------------------
> 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/bcb794a9/attachment.html>