[PATCH] D94268: Allow _mm_empty() (via llvm.x86.mmx.emms) to be a no-op without MMX.

James Y Knight via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Jan 8 13:34:03 PST 2021


jyknight added a comment.

In D94268#2485958 <https://reviews.llvm.org/D94268#2485958>, @pengfei wrote:

> Is inline assembly the only case `emms` instruction will be needed? But inline assembly doesn't enable `mmx` attribute automatically, right? E.g. https://godbolt.org/z/43ases

Yes, inline or external asm should be the only reason there should be any MMX register usage when all is done here. After this patch, the default is still to have mmx enabled by default with sse, despite that clang won't use it. But users can pass -mno-mmx if they like. And, yes, clang only requires -mmmx if you use the "y" asm constraint, not if you use mmx instructions inside the asm string.

I wrote this patch because making it a no-op is the same behavior GCC has. However, I'm not sure this is necessarily the right way to go. On the plus side for this patch, it allows intrinsic-using code to stop emitting spurious emms instructions, if compiled with -mno-mmx. However, the negative is that inline-asm code which _doesn't_ use the "y" constraint might still be using MMX within an asm blob, and be depending on calls to _mm_empty() outside of the asm, and such code would be silently broken when compiled with -mno-mmx.

At first, I thought that most uses of inline-asm would be using constraints, but after looking around at existing MMX asm, it seems that nearly all of it does _not_ use a "y" constraint or even clobber any fpu or mmx registers. And they do also depend on _mm_empty() in combination with their unmarked inline asm. Which...now that I think about it more, makes passing -mno-mmx to the compiler almost entirely pointless.

So, now I'm thinking I'll just drop this change, actually.

> Analyzing asm block and appending the `mmx` attribute if we see `mmx` instructions might be needed. But if we do the analysis, just adding an `emms` instruction at the end of the block seems better.

Analyzing assembly strings is rather fraught -- I don't think we should be doing that. Having the compiler add emms to the end of the block might be nice -- and if we had a proper clobber for "switched into MMX state" then we could do that, perhaps. But we don't, and designing new features for MMX won't help anyone now, because only legacy code is _knowingly_ using MMX. (The biggest issue with the intrinsics is that people are unknowingly using MMX.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94268



More information about the cfe-commits mailing list