Timeline for What were the last C & C++ compilers to support automatic MMX vectorisation?
Current License: CC BY-SA 4.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 4 at 22:10 | comment | added | David Gardner | Codeplay made a commercial auto-vectorising C/C++ compiler which supported MMX amongst other instruction set extensions for Windows PCs. Mostly aimed at games development and not open-source. Not sure what dates it was supported until to count as the "last" one though. E.g. web.archive.org/web/20041204163407/http://www.codeplay.com/… | |
| Nov 1 at 19:20 | comment | added | Nate Eldredge | Sufficiently early versions of the Intel C/C++ Compiler, maybe? The first version shown on Wikipedia is 4.0 in 1999 which announced SSE support, so earlier versions might have done MMX only. | |
| Nov 1 at 16:55 | comment | added | Raffzahn | @StanislawPetreus Not really. Intrinsics are a way to nudge a compiler toward a certain functional implementation, while (inline) Assembly is the tool to force a specific, exact implementation. It's up to the compiler - and especially optimzier/backend - what instructions are used to get the result. That way intrinsics stay mostly portable (if supported) using all the compilers benefits. After all, that' what HLL use is about: not specifying certain implementation, but describing the tak in a more abstract way. So having the compiler replace MMX by SSE is exactly what the "contact" is about. | |
| Nov 1 at 15:33 | comment | added | Jean-François Fabre | I'm sure I used vectorisation on SSE with icc without assembly around 2005/2006, where gcc wasn't able to do it. it was probably using intrinsics | |
| Nov 1 at 15:25 | comment | added | Stanislaw Petreus | @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 | |
| Nov 1 at 15:22 | comment | added | Stanislaw Petreus | @user3528438 while it seems like GCC has the ability to emit some broken MMX, it does not seem to be able to vectorise using MMX | |
| Nov 1 at 13:22 | comment | added | user3840170 | @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? | |
| Nov 1 at 12:45 | comment | added | user3528438 | gcc has -march=pentium-mmx option. Does it not do anything? | |
| Nov 1 at 12:40 | comment | added | Stanislaw Petreus | @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 | |
| Nov 1 at 12:34 | comment | added | Robert Harvey | "why did they not just remove the intrinsics if they wanted them gone?" For backwards compatibility. | |
| S Nov 1 at 8:56 | review | First questions | |||
| Nov 1 at 13:13 | |||||
| S Nov 1 at 8:56 | history | asked | Stanislaw Petreus | CC BY-SA 4.0 |