[llvm-dev] Proposal to remove MMX support.

[Simon Pilgrim via llvm-dev]

On 31/08/2020 22:13, Eli Friedman via llvm-dev wrote:
>
> (reply inline)
>
> *From:* James Y Knight <jyknight at google.com>
> *Sent:* Monday, August 31, 2020 1:31 PM
> *To:* Eli Friedman <efriedma at quicinc.com>
> *Cc:* llvm-dev at lists.llvm.org
> *Subject:* [EXT] Re: [llvm-dev] Proposal to remove MMX support.
>
> On Mon, Aug 31, 2020 at 3:02 PM Eli Friedman <efriedma at quicinc.com 
> <mailto:efriedma at quicinc.com>> wrote:
>
>     Broadly speaking, I see two problems with implicitly enabling MMX
>     emulation on a target that has SSE2:
>
>     1.The interaction with inline asm.  Inline asm can still have MMX
>     operands/results/clobbers, and can still put the processor in MMX
>     mode.  If code is mixing MMX intrinsics and inline asm, there
>     could be a significant penalty to moving values across register
>     files. And it’s not clear what we want to do with _mm_empty():
>     under full emulation, it should be a no-op, but if there’s MMX
>     asm, we need to actually clear the register file.
>
> Moving data between the register files in order to call an inline asm 
> is not a correctness issue, however, just a potential performance 
> issue. The compiler will insert movdq2q and movq2dq instructions as 
> needed to copy the data (introduced in SSE2). If this is slow in 
> current CPUs, then your code will be slow...but, if such code is being 
> used in a performance critical location now, it really shouldn't be 
> using MMX still, so I don't think this is a seriosu issue.
>
> For _mm_empty, I think the best thing to do is to follow what GCC did, 
> and make it a no-op only if MMX is disabled, and have it continue to 
> emit EMMS otherwise -- even though that is usually a waste.
>
> Right, besides _mm_empty, the emulation is completely transparent in 
> terms of correctness. I guess we can decide we don’t care if we mess 
> up the performance.
>
> The penalty for emitting an unnecessary _mm_empty is small enough we 
> could just ignore it, I guess.
>
>     1.The calling convention problem; your description covers this.
>
> Well, I covered it...but I didn't come to an actual conclusion there. :)
>
> Given that nobody else has noticed so far, it’s likely nobody will 
> ever notice.  People don’t tend to mix compilers in that sort of 
> situation, I guess.
>
>     If we add an explicit opt-in, I don’t see any problem with
>     emulation (even on non-x86 targets, if someone implements that).
>
>     If we’re going make changes that could break people’s software,
>     I’d prefer it to break with a compile-time error: require the user
>     affirmatively state that there aren’t any interactions with
>     assembly code. For the MMX intrinsics in particular, code that’s
>     using intrinsics is likely to also be using inline asm, so the
>     interaction is important.
>
> It is a compile-time error to use MMX ("y" constraint) operands and 
> outputs for inline-asm with MMX disabled. SoIf _mm_empty() only 
> becomes a no-op when MMX is disabled, that should address the vast 
> majority of the issue.
>
> There is a case where it can go wrong, still: it is not an error to 
> use MMX in asm, even with mmx disabled. Thus it is possible that an 
> inline-asm statement which has no MMX ins/outs, but which does use MMX 
> registers, and which depends on a subsequent call to _mm_empty() to 
> reset the state, could be broken at runtime if compiled with -mno-mmx. 
> I think this is unlikely to occur in the wild, but it's possible. It's 
> also possible that a standalone asm function might use MMX, and depend 
> on its caller to clear the state (even though it should be clearing 
> the mmx state itself).
>
> If we’re going to translate _mm_empty to emms, we might as well do it 
> even under “-msse2 -mno-mmx”.
>
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.

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).

> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200903/d6f55de3/attachment.html>