[PATCH] D82862: [ThinLTO] Always parse module level inline asm with At&t dialect

Hans Wennborg via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jan 14 10:15:28 PST 2021


hans added a comment.

In D82862#2498242 <https://reviews.llvm.org/D82862#2498242>, @uweigand wrote:

> Hi @hans , we're having some issues with using the AssemblerDialect mechanism to support both the GNU assembler and the IBM HLASM assembler in the SystemZ back-end.     See also the discussion started here: https://lists.llvm.org/pipermail/llvm-dev/2020-November/146875.html
>
> One of the issues that showed up is what you're refering to above:
>
>> That flag however should not affect the *parsing* of inline assembly in the program.
>
> I'm wondering why this is true.  I mean, it is true that the flag currently does not affect parsing of inline asm, but I'm wondering whether it *should* be that way.
>
> Note that the `-x86-asm-syntax=intel` LLVM flag is used to implement the `-masm=intel` clang **command line option**, which exists also in GCC and where hopefully the two compilers should be compatible.  But in GCC, that flag is documented to affect parsing of inline assembly just like it affects output.   See https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/x86-Options.html#x86-Options
>
>> -masm=dialect
>>
>>   Output assembly instructions using selected dialect. Also affects which dialect is used for basic asm (see Basic Asm) and extended asm (see Extended Asm). Supported choices (in dialect order) are ‘att’ or ‘intel’. The default is ‘att’. Darwin does not support ‘intel’.
>
> What is the reason for treating this differently in LLVM?

The motivation for my change was really just to make ThinLTO compiles work the same as non-ThinLTO ones.

Maybe the fact that -x86-asm-syntax=intel doesn't affect inline asm is a bug. I wasn't aware that Clang and GCC's -masm= flags behaved differently in that way, but that certainly suggests there's a problem here.

(From clang-cl's point of view we just want to set the *output* dialect to Intel, but we could invent a different flag for that if necessary.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82862



More information about the llvm-commits mailing list