is there an instruction that broadcasts a single precision float from memory to the four slots in a xmmx register? (similar to movddup for doubles)
Currently using :
movss xmm0, dword []
shufps xmm0,xmm0,0

Although you will have to wait a while for the instruction to be available.

If you don't want to wait for the later CPUs to be released you can have it now with: Loads a single 128bit vector with 4 duplications of a single 32bit memory value.

although you will need and ARM CPU for it to work

Ok, I get it. It is not possible right now. Ha - is arm ahead of x86?

They are on different race tracks. So trying to judge who is ahead of whom is like trying to decide whether the velodrome riders are ahead of the pool swimmers.

Anyway you are impliying that ones are evolving faster than others...

Ofcourse there is:
shufps xmm0, dword [],0
pshufd xmm0, dword [],0

Why wouldn't you use them?


It looks just like you are looking for an instruction IMUL4 eax shortcut, when you already have SHL eax,2 I think its really fast.

Because the operand size in your code is not really available?

tthsqe,

Single pshufd xmmx, dqword [mem32], 0 would suffice, if you don't mind #GP when mem32 is not properly aligned.

BTW, besides the problem pshufd has regarding memory alignment (which makes its use with float arrays impossible), and that it has the extra need for SSE2, could it incur in some performance hit? pshufd will probably mark the two halves of the xmm register as INT, so the next floating point operation MAY be penalized for that, no?

If you want to load unaligned dwords, you can do this:

I know they're immediates, but there's always a way in your code to determine where you load your data.
pshufd will switch to INT indeed and you pay a clock for that but in my experience its too small to notice. MOVSS intrinsic is not encouraged by Intel and they say the use of MOVPS/MOVPD is better in this case.

And if you don't want to shuffle between INT/FPU, you can always do the all-INT way (and still use MOV*):

but I don't see it beating pshufd xmm0,[mem32],0 in speed nor size.

Silly me for thinking that the integer version

of

would shuffle them the same way. I just assumed they would be consistent.

I think i'll accept the fourfold increase in code size and go with that last one by Madis.

Oh dear - of course - the shufps will take BOTH inputs and shuffle them. That is why I always use the packed one. Oops!

Who's the bad boy here Intel? AMD? both?

I expect it is a hangover from the time when all SSE was still only done with 64bit operations internally.

Like loop unrolling, something that I've not even sightly thought about when talked about its inability to be used for float arrays

This simple SSE question has grown out of hands but there are some not very simple ideas to even unroll float arrays.

You can first load xmm0 with movdqa const[1.0,2.0,3.0,4.0]
then add const[4.0,4.0,4.0,4.0] to this register every loop.

Now you can effectively use these constants to calculate linearly every number you want. Actually Intel C Compiler will optimize float loop counters all by itself. Of course it prefers integer loop indexes.