digitalmars.D - core.simd 3 operand instructions?
- Benjamin Thaut <code benjamin-thaut.de> Sep 06 2012
- Walter Bright <newshound2 digitalmars.com> Sep 06 2012
- Benjamin Thaut <code benjamin-thaut.de> Sep 07 2012
- "jerro" <a a.com> Sep 06 2012
- "jerro" <a a.com> Sep 06 2012
- Manu <turkeyman gmail.com> Sep 12 2012
Looking at core.simd I noticed that all simd instructions that take 3 operands (usually two operands and some kind of constant third value), are commented out for the opcodes. Most likely because __simd() does not have a 4th parameter which could be used to pass in the additional value for some of the opcodes. Are there plans to fix this? Because for example the shuffle instructions are pretty important (try doing a cross product without simd shuffle instructions...) Kind Regards Benjamin Thaut
Sep 06 2012
On 9/6/2012 12:21 PM, Benjamin Thaut wrote:Looking at core.simd I noticed that all simd instructions that take 3 operands (usually two operands and some kind of constant third value), are commented out for the opcodes. Most likely because __simd() does not have a 4th parameter which could be used to pass in the additional value for some of the opcodes. Are there plans to fix this? Because for example the shuffle instructions are pretty important (try doing a cross product without simd shuffle instructions...)
simd support is very important, but I put it on the back burner for the moment while applying the paddles to the Win64 compiler.
Sep 06 2012
Benjamin Thaut <code benjamin-thaut.de> Am 06.09.2012 22:45, schrieb Walter Bright:On 9/6/2012 12:21 PM, Benjamin Thaut wrote:Looking at core.simd I noticed that all simd instructions that take 3 operands (usually two operands and some kind of constant third value), are commented out for the opcodes. Most likely because __simd() does not have a 4th parameter which could be used to pass in the additional value for some of the opcodes. Are there plans to fix this? Because for example the shuffle instructions are pretty important (try doing a cross product without simd shuffle instructions...)
simd support is very important, but I put it on the back burner for the moment while applying the paddles to the Win64 compiler.
That is nice to hear, I would prefer 64 bit support on windows over simd any time ;-) Kind Regards Benjamin Thaut
Sep 07 2012
On Thursday, 6 September 2012 at 19:21:22 UTC, Benjamin Thaut wrote:Looking at core.simd I noticed that all simd instructions that take 3 operands (usually two operands and some kind of constant third value), are commented out for the opcodes. Most likely because __simd() does not have a 4th parameter which could be used to pass in the additional value for some of the opcodes. Are there plans to fix this? Because for example the shuffle instructions are pretty important (try doing a cross product without simd shuffle instructions...) Kind Regards Benjamin Thaut
I can't answer your question, but if you are using GDC, you could use gcc builtins . They have the same names as in GCC - take a look at *mmintrin.h files to find out SSE builtin names). For LDC, you could use pragma intrinsic(http://www.dsource.org/projects/ldc/wiki/Docs) and pragma shufflevector. You declare function that you want to compile to llvm shufflevector instruction like this: pragma(shufflevector) float4 shufflevector(float4, float4, int, int, int, int); Then shufflevector() is used in the same way as Clang's __builtin_shufflevector (http://clang.llvm.org/docs/LanguageExtensions.html#__builtin_shufflevector)
Sep 06 2012
On Friday, 7 September 2012 at 05:56:19 UTC, jerro wrote:On Thursday, 6 September 2012 at 19:21:22 UTC, Benjamin Thaut wrote:Looking at core.simd I noticed that all simd instructions that take 3 operands (usually two operands and some kind of constant third value), are commented out for the opcodes. Most likely because __simd() does not have a 4th parameter which could be used to pass in the additional value for some of the opcodes. Are there plans to fix this? Because for example the shuffle instructions are pretty important (try doing a cross product without simd shuffle instructions...) Kind Regards Benjamin Thaut
I can't answer your question, but if you are using GDC, you could use gcc builtins . They have the same names as in GCC - take a look at *mmintrin.h files to find out SSE builtin names). For LDC, you could use pragma intrinsic(http://www.dsource.org/projects/ldc/wiki/Docs) and pragma shufflevector. You declare function that you want to compile to llvm shufflevector instruction like this: pragma(shufflevector) float4 shufflevector(float4, float4, int, int, int, int); Then shufflevector() is used in the same way as Clang's __builtin_shufflevector (http://clang.llvm.org/docs/LanguageExtensions.html#__builtin_shufflevector)
I forgot to mention Manu's std.simd (https://github.com/TurkeyMan/phobos/blob/master/std/simd.d). It is supposed to be wrapper around compiler specific intrinsics. If your are using SIMD mostly for operation on geometric vectors, it should fit your use case well (for example, it already includes a cross3 function). It currently only really supports GDC, though.
Sep 06 2012
--20cf3071ceb474d2e104c97eb2c9 Content-Type: text/plain; charset=UTF-8 On 7 September 2012 09:05, jerro <a a.com> wrote:On Friday, 7 September 2012 at 05:56:19 UTC, jerro wrote:On Thursday, 6 September 2012 at 19:21:22 UTC, Benjamin Thaut wrote:Looking at core.simd I noticed that all simd instructions that take 3 operands (usually two operands and some kind of constant third value), are commented out for the opcodes. Most likely because __simd() does not have a 4th parameter which could be used to pass in the additional value for some of the opcodes. Are there plans to fix this? Because for example the shuffle instructions are pretty important (try doing a cross product without simd shuffle instructions...) Kind Regards Benjamin Thaut
I can't answer your question, but if you are using GDC, you could use gcc builtins . They have the same names as in GCC - take a look at *mmintrin.h files to find out SSE builtin names). For LDC, you could use pragma intrinsic(http://www.dsource.**org/projects/ldc/wiki/Docs<http://www.dsource.org/projects/ldc/wiki/Docs>) and pragma shufflevector. You declare function that you want to compile to llvm shufflevector instruction like this: pragma(shufflevector) float4 shufflevector(float4, float4, int, int, int, int); Then shufflevector() is used in the same way as Clang's __builtin_shufflevector (http://clang.llvm.org/docs/** LanguageExtensions.html#__**builtin_shufflevector<http://clang.llvm.org/docs/LanguageExtensions.html#__builtin_shufflevector> )
I forgot to mention Manu's std.simd (https://github.com/TurkeyMan/** phobos/blob/master/std/simd.d<https://github.com/TurkeyMan/phobos/blob/master/std/simd.d> )**. It is supposed to be wrapper around compiler specific intrinsics. If your are using SIMD mostly for operation on geometric vectors, it should fit your use case well (for example, it already includes a cross3 function). It currently only really supports GDC, though.
Yeah, it's kinda waiting for the missing bits from DMD before I can finish it off. GDC is pretty close, though there are some missing fallback paths for the operations that have efficient SSE4.1 opcodes (which should also implement an SSE2 fallback path). I started preliminary ARM support too, and I got LDC building recently, so I might add that in soon. I don't think it's purely for geometry, all the integer stuff is there, along with permutation and saturating integer operations. But it certainly offers a lot of helpers for geometry work. --20cf3071ceb474d2e104c97eb2c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 7 September 2012 09:05, jerro <span dir=3D"lt= r"><<a href=3D"mailto:a a.com" target=3D"_blank">a a.com</a>></span> = wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord= er-left:1px #ccc solid;padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">On Friday, 7 September 2012 at 05:5= 6:19 UTC, jerro wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On Thursday, 6 September 2012 at 19:21:22 UTC, Benjamin Thaut wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Looking at core.simd I noticed that all simd instructions that take 3 opera= nds (usually two operands and some kind of constant third value), are comme= nted out for the opcodes. Most likely because __simd() does not have a 4th = parameter which could be used to pass in the additional value for some of t= he opcodes.<br> <br> Are there plans to fix this? Because for example the shuffle instructions a= re pretty important (try doing a cross product without simd shuffle instruc= tions...)<br> <br> Kind Regards<br> Benjamin Thaut<br> </blockquote> <br> I can't answer your question, but if you are using GDC, you could use g= cc builtins . They have the same names as in GCC - take a look at *mmintrin= .h files to find out SSE builtin names). For LDC, you could use pragma intr= insic(<a href=3D"http://www.dsource.org/projects/ldc/wiki/Docs" target=3D"_= blank">http://www.dsource.<u></u>org/projects/ldc/wiki/Docs</a>) and pragma= shufflevector. You declare function that you want to compile to llvm shuff= levector instruction like this:<br> <br> pragma(shufflevector)<br> =C2=A0 =C2=A0 float4 shufflevector(float4, float4, int, int, int, int);<br> <br> Then shufflevector() is used in the same way as Clang's __builtin_shuff= levector (<a href=3D"http://clang.llvm.org/docs/LanguageExtensions.html#__b= uiltin_shufflevector" target=3D"_blank">http://clang.llvm.org/docs/<u></u>L= anguageExtensions.html#__<u></u>builtin_shufflevector</a>)<br> </blockquote> <br></div></div> I forgot to mention Manu's std.simd (<a href=3D"https://github.com/Turk= eyMan/phobos/blob/master/std/simd.d" target=3D"_blank">https://github.com/T= urkeyMan/<u></u>phobos/blob/master/std/simd.d</a>)<u></u>. It is supposed t= o be wrapper around compiler specific intrinsics. If your are using SIMD mo= stly for operation on geometric vectors, it should fit your use case well (= for example, it already includes a cross3 function). It currently only real= ly supports GDC, though.<br> </blockquote></div><br><div>Yeah, it's kinda waiting for the missing bi= ts from DMD before I can finish it off.</div><div>GDC is pretty close, thou= gh there are some missing fallback paths for the operations that have effic= ient SSE4.1 opcodes (which should also implement an SSE2 fallback path).</d= iv> <div>I started preliminary ARM support too, and=C2=A0I got LDC building rec= ently, so I might add that in soon.</div><div><br></div><div>I don't th= ink it's purely for geometry, all the integer stuff is there, along wit= h permutation and saturating integer operations. But it certainly offers a = lot of helpers for geometry work.</div> --20cf3071ceb474d2e104c97eb2c9--
Sep 12 2012