<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 31/08/2020 22:13, Eli Friedman via
llvm-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:BY5PR02MB7092804F479C4E3D9584C037CA510@BY5PR02MB7092.namprd02.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}mso-list-id:680818291;
mso-list-template-ids:-1197061082;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">(reply inline)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-left:.5in"><b>From:</b>
James Y Knight <a class="moz-txt-link-rfc2396E" href="mailto:jyknight@google.com"><jyknight@google.com></a>
<br>
<b>Sent:</b> Monday, August 31, 2020 1:31 PM<br>
<b>To:</b> Eli Friedman <a class="moz-txt-link-rfc2396E" href="mailto:efriedma@quicinc.com"><efriedma@quicinc.com></a><br>
<b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<b>Subject:</b> [EXT] Re: [llvm-dev] Proposal to remove MMX
support.<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in">On Mon, Aug
31, 2020 at 3:02 PM Eli Friedman <<a
href="mailto:efriedma@quicinc.com" target="_blank"
moz-do-not-send="true">efriedma@quicinc.com</a>>
wrote:<o:p></o:p></p>
</div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC
1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in">Broadly
speaking, I see two problems with implicitly
enabling MMX emulation on a target that has SSE2:<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in;text-indent:-.25in;mso-list:l1
level1 lfo1">
<!--[if !supportLists]--><span
style="mso-list:Ignore">1.<span style="font:7.0pt
"Times New Roman"">
</span></span><!--[endif]-->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.<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="margin-left:.5in">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The penalty for emitting an
unnecessary _mm_empty is small enough we could just
ignore it, I guess.<span style="font-size:12.0pt"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC
1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in;text-indent:-.25in;mso-list:l0
level1 lfo2">
<!--[if !supportLists]--><span style="mso-list:Ignore">1.<span
style="font:7.0pt "Times New Roman"">
</span></span><!--[endif]-->The calling convention
problem; your description covers this.<o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="margin-left:.5in">Well, I
covered it...but I didn't come to an actual conclusion
there. :)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC
1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in">If
we add an explicit opt-in, I don’t see any problem
with emulation (even on non-x86 targets, if someone
implements that).<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in">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.<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">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).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">If we’re going to translate _mm_empty
to emms, we might as well do it even under “-msse2
-mno-mmx”.</p>
</div>
</div>
</div>
</div>
</blockquote>
<p>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
(<a class="moz-txt-link-freetext" href="https://gcc.gnu.org/legacy-ml/gcc-patches/2019-02/msg00061.html">https://gcc.gnu.org/legacy-ml/gcc-patches/2019-02/msg00061.html</a>),
we could then decide how to enable this by default for x86_64 etc.</p>
<p>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).<br>
</p>
<blockquote type="cite"
cite="mid:BY5PR02MB7092804F479C4E3D9584C037CA510@BY5PR02MB7092.namprd02.prod.outlook.com">
<div class="WordSection1">
<div>
<div>
<div>
<p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal">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.</p>
</div>
</div>
</div>
</div>
</blockquote>
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.<br>
</body>
</html>