<div dir="ltr"><div dir="ltr">On Thu, Sep 3, 2020 at 4:52 AM Simon Pilgrim via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
    <div>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 href="https://gcc.gnu.org/legacy-ml/gcc-patches/2019-02/msg00061.html" target="_blank">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.<br></div>
    <p></p></div></blockquote><div>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.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><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></div></blockquote><div>Absolutely agreed on this.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
    </p>
    <blockquote type="cite">
      <div>
        <div>
          <div>
            <div>
              <p class="MsoNormal"><u></u><u></u></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></div></blockquote><div><br></div><div>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.</div><div><br></div></div></div>