[llvm-dev] Proposal to remove MMX support.

[James Y Knight via llvm-dev]

On Thu, Sep 3, 2020 at 4:52 AM Simon Pilgrim via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Regarding D86855 - I'd have preferred to see this as an opt-in solution
> behind a "mmx-on-sse" style clang attribute - similar to gcc's attempt (
> https://gcc.gnu.org/legacy-ml/gcc-patches/2019-02/msg00061.html), we
> could then decide how to enable this by default for x86_64 etc.
>
> Can you explain why you would prefer this? I agree it would be possible,
but as I said in my proposal, I don't see real value in continuing to
support the MMX version, and it has a significant amount of additional
complexity.

> We also need some decent test coverage to check for subtle diffs in the
> instructions (e.g. pshufb mmx and pshufb xmm act differently as they have
> different index ranges).
>
Absolutely agreed on this.

> There are probably bugs in the interaction between MMX operands/results to
> inline asm and x87 operations.  But I guess that’s sort of orthogonal to
> the rest of this.
>
> I'm worried that whatever we go with we need to just get on with fixing
> the (F)EMMS scheduling bugs causing x87/mmx mixing. Plus we probably could
> then get PR42319 done more easily to insert (F)EMMS as required.
>

I think we probably could close these bugs as wontfix if the only thing
remaining which is using MMX is inline-asm. If you're using mmx in
inline-assembly, you probably already aren't mixing with x87 fpu usage.
Additionally, there is not that much MMX inline-asm in use anymore. While
the 64-bit vector intrinsics are easy to use without realizing the
implications in terms of MMX weirdness, the same is not true for MMX
assembly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200903/f6e66564/attachment.html>