8

It was suggested to me to move this question from SO to here.

There was a relatively short (in tech terms, at least) period during which MMX was the only way to vectorise integer operations on the x86, as the Pentium MMX came out in 1997, and SSE2 came out in 2000. Using it seems to have always been especially unergonomic, though.

Modern C and C++ compilers do not seem to be able to vectorise using MMX properly. For GCC, this seems to be a problem in figuring out where to use emms, and doesn't seem to have ever supported automatic emission of MMX. The same goes for MSVC, and even ICC (as far as I know) in the present, if not the past. In all of these, it seems that, if one wanted the MMX registers used, then the solution is either inline assembly, intrinsics, or a module written entirely in asm. Even in that case, Clang makes the bizarre choice of making MMX intrinsics emit SSE2 assembly, meaning it is now impossible to actually output MMX with Clang intrinsics (why did they not just remove the intrinsics if they wanted them gone?)

Was there a historical version of a modern compiler, or a historical compiler now discontinued, for C and C++ that could auto-vectorise using MMX? If so, which?

10
  • 2
    "why did they not just remove the intrinsics if they wanted them gone?" For backwards compatibility. Commented Nov 1 at 12:34
  • 1
    @RobertHarvey I can see that, but if the point is to discontinue support for MMX, it might be more prudent to explicitly error out and inform the user that they should be porting to SSE2, or to use Clang 19 or lower (not that Clang 19 is particularly old!). I'm struggling to think of where this kind of compatibility would be desired when compiling with a compiler from 2025 and not just erroring out gracefully with an informative message about MMX removal... Maybe I'm just thinking about it the wrong way Commented Nov 1 at 12:40
  • 2
    gcc has -march=pentium-mmx option. Does it not do anything? Commented Nov 1 at 12:45
  • 1
    @StanislawPetreus If the compiler can reproduce the semantics of the intrinsics accurately, why should the program care that the binary does not actually contain MMX instructions? Commented Nov 1 at 13:22
  • 1
    @user3840170 I feel that goes against the philosophy of intrinsics in general; they're, at least in my opinion, meant to be a function that predictably maps to one or occasionally more assembly instructions in a very clear and easy-to-reason way. If it maps to something other than what's expected, that "contract" is IMO broken. Other functions that aren't intrinsics should cover this use case, not intrinsics. Like I said, I might be thinking about it the wrong way, but I see this as a failure of intrinsic misappropriation rather than a desirable behaviour Commented Nov 1 at 15:25

0

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.