Does dmd have SSE intrinsics?

[Don]

dsimcha wrote:
> == Quote from Don (nospam at nospam.com)'s article
>> Jeremie Pelletier wrote:
>>> While writing SSE assembly by hand in D is fun and works well, I'm wondering
> if the compiler has intrinsics for its instruction set, much like xmmintrin.h in C.
>>> The reason is that the compiler can usually reorder the intrinsics to optimize
> performance.
>>> I could always use C code to implement my SSE routines but then I'd lose the
> ability to inline them in D.
>> I know this is an old post, but since it wasn't answered...
>> Make sure you know what the SSE intrinsics actually *do* in VC++/Intel!
>> I've read many complaints about how poorly they perform on all compilers
>> -- the penalty for allowing them to be reordered is that extra
>> instructions are often added, which means that straightforward C code is
>> sometimes faster!
>> In this regard, I'm personally excited about array operations. I think
>> the need for SSE intrinsics and vectorisation is a result of abstract
>> inversion: the instruction set is higher-level than the "high level
>> language"! Array operations allow D to catch up with asm again. When
>> array operations get implemented properly, it'll be interesting to see
>> how much need for SSE intrinsics remains.
> 
> What's wrong with the current implementation of array ops (other than a few misc.
> bugs that have already been filed)?  I thought they already use SSE if available.

(1) They don't take advantage of fixed-length arrays. In particular, 
operations on float[4] should be a single SSE instruction (no function 
call, no loop, nothing). This will make a huge difference to game and 
graphics programmers, I believe.
(2) The operations don't block on cache size.
(3) DMD doesn't allow you to generate code assuming a minimum CPU 
capabilities. (In fact, when generating inline asm, the CPU type is 
8086! (this is in bugzilla)) This limits the possible use of (1).

It's issue (1) which is the killer.