[llvm-dev] MS assembly integer literal question

Reid Kleckner via llvm-dev llvm-dev at lists.llvm.org
Wed Sep 23 15:14:45 PDT 2020


I think disabling support for the 1to4 syntax in masm-mode would be fine.
No need to wait until bcast is implemented. It's probably better to keep
things moving.

On Wed, Sep 23, 2020 at 2:04 PM Eric Astor <epastor at google.com> wrote:

> Hi all,
>
> I've got an interesting AsmLexer failure (originally found as a breakage
> post-D87400 <https://reviews.llvm.org/D87400>, now reverted).
> ms-inline-asm-avx512.c
> <https://github.com/llvm/llvm-project/blob/a36ddf0aa9db5c1086e04f56b5f077b761712eb5/clang/test/CodeGen/ms-inline-asm-avx512.c#L26-L27> includes
> the line:
> __asm vaddps xmm1, xmm2, [c]{1to4}
>
> The trouble is: MASM doesn't use the {1toX} syntax for the AVX-512
> instructions. Instead, they implemented a "bcst" keyword, which would
> roughly apply as:
> __asm vaddps xmm1, xmm2, dword bcst [c]
> See
> https://devblogs.microsoft.com/cppblog/microsoft-visual-studio-2017-supports-intel-avx-512/#embedded-broadcast
>
> Can we remove support for the {1toX} syntax in MASM contexts, or do we
> need to keep it until we can implement "bcst" support?
>
> Context:
>
> The current implementation (before my change) doesn't support this "bcst"
> keyword, so it isn't actually following MASM - but no one noticed. x64 MSVC
> doesn't allow inline assembly, so there's nothing to compare to in that
> context.
>
> The problem: I'm trying to add support for full MASM-style integer
> literals in our inline assembly when targeting MSVC compatibility (or at
> least in the upcoming LLVM-ML project). The "1to4" syntax conflicts with
> that, as "1t" gets lexed as an integer literal, with the "t" recognized as
> a decimal radix specifier. We can special-case that away by checking for an
> "o" following the "t", but that might have false positives.
>
> Thanks,
> - Eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200923/aefed61d/attachment.html>


More information about the llvm-dev mailing list