[PATCH] D95444: Allow GNU inline asm using target-specific dialect variant

Reid Kleckner via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Feb 5 14:42:23 PST 2021


rnk added a comment.

In D95444#2545646 <https://reviews.llvm.org/D95444#2545646>, @hubert.reinterpretcast wrote:

> In D95444#2542739 <https://reviews.llvm.org/D95444#2542739>, @rnk wrote:
>
>> Clang actually supports mixing GCC and MSVC inline asm in the same translation unit, and it uses the dialect flag in the IR to control this (I think). This is important if you want to support LTO between two TUs that use GCC and HLASM. Maybe there is exactly zero inline asm that uses GCC-style asm for SystemZ, so maybe this isn't a concern, but I thought I'd ask.
>
> I'm concerned that "GCC" is overloaded here. The "GCC" that contrasts with MSVC is a C/C++ level parsing difference. The "GCC" that contrasts with HLASM has to do with the string content in a GNU-style inline assembly construct.

Yes, sorry, I meant the assembly dialect that the GNU binutils assembler parses. What I'm trying to get at is that you might want to support separate blobs that use different dialects:

  void foo() { asm volatile ("gnu style asm"); }
  void bar() { asm volatile ("HLASM style asm"); }

If there is one global setting for the inline asm dialect, this won't work. You could create a flag to control the setting, but then if you want to use LTO on two objects that use different assembly dialects, the command line flag isn't sufficient. To fully address this use case, you would want to put the dialect on each inline assembly blob, similar to the way we handle the existing intel/gnu dialect flag.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D95444/new/

https://reviews.llvm.org/D95444



More information about the llvm-commits mailing list