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

[Reid Kleckner via llvm-dev]

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>