Agreed already it should wait to get the current version out , but you wrote
..
> I'm also fairly confident that we are in no worse a position than anybody
else.
In C you can often do use asm {} for this , while Intrinsic are ok for
output registers already in the format they do badly at the edges eg
const __m128i Reg0 = _mm_set_epi32 ( i,i,i,i);
//compiler does this
//movd xmm0, esi
//movd xmm1, esi
//movd xmm2, esi
//movd xmm3, esi
//mov DWORD PTR _prt$8074[ebp], eax //load ptr address
//punpckldq xmm2, xmm0
//punpckldq xmm3, xmm1
//punpckldq xmm3, xmm2
Not so good..i is a loop counter (esi).
_mm_stream_si128((__m128i *) prt ,Reg0 );
//movntdq XMMWORD PTR [eax], xmm3
Good.
This forces asm I wouldn't be surprised in c if the majority of these
algorithms do simd parts in asm instead of intrinsic. And asm{} is ot part
of bitc.
IMHO SIMD should be adopted as something like
Phase1 ) Reserve register keywords for future use ( including 256 bit ymm)
Phase2) Implement SSE non SIMD instructions like mov for Temporal and
Normal cache usage , these are not SIMD but normal instructions that just
use SIMD registers and are very common in todays libs.
Phase3) Fuller SIMD support either around converting to simd idealized
forms and still use intirinsics , using SIMD even for ints in a SIMD heavy
function eg loop counters ( to save conversion costs) or full language
support. The real work is more in the compiler and optimization than the
language.
Surprisingly (to me) there seems to be quite a bit of research in the SIMD
language field (esp around Fortan and massive parallelism) which need to
be welded to the limitations of the current HW , implementation is not
trivial , however the rewards in terms of language take up are very high. C
programmers don't deal with asm because they like it..
Ben
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
