Just for a bit more info, I replied to someone on the main D newsgroup about what I've been doing thus far:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=100436 > On Sat, Nov 7, 2009 at 8:49 AM, Christian Kamm <[email protected]> wrote: [snip] > > As far as I remember, the problem with the SSE intrinsics is that there's > > no D > > type that matches llvm's vector types > > (http://www.llvm.org/docs/LangRef.html#t_vector). And that means getting > > explicit access to the intrinsic from D code will not be easy. > > > I think Tomas looked into this at some point, maybe he can offer some advice > > to get you started. > > > Note that the LLVM optimizer should already make use of the intrinsics. Yeah, but do the LLVM intrinsics for vector types actually cover all of the range of Intel intrinsics for SSE? I'll bet not, but probably the majority of the operations I need are already taken care of by those LLVM vector intrinsics. I wonder how they forward on those extra intrinsics in clang and llvm-gcc? On Nov 7, 7:35 am, Tomas Lindquist Olsen <[email protected]> wrote: > The problem was indeed introducing the vector types into the D type system. > Fixed-size array seems like a perfect fit, but in D1 they are treated > as reference types (and are not returnable). > I never found the best way to go about it... and adding a completely > new type into the frontend seemed like a lot of work D2 will pass the static arrays around by value, and they will be returnable. How hard is it to add a switch to enable just that behavior in ldc even for D1? I'd imagine mucking with the frontend like that could be a pain, but Walter does have that recent change that you can peek at in dmd 2.036 for reference. What about introducing the types as just a struct with a float[4] in it? Is there something in the x86-64 ABI that makes it a bad idea to stuff that in an xmm register on return? Perhaps there's a simple flag that could be set on the struct type that notes it is intended for SIMD registers? I should probably stop making suggestions because I really have no idea how hard any of that would be, but if you guys want I could make my own attempt at implementing parts of this in ldc and report back. I haven't got gobs of free time, but I could kick it around a bit if you point me to the parts of the code that are likely relevant. On a philosophical note, I also don't think adding a completely new type to the frontend is a good idea. I would imagine rather you would want to (in D2, really): * Make all static arrays of basic types (byte, char flavors, short flavors, int flavors, float, double) all be marked automatically as the underlying LLVM vector types. When returning them by value, LLVM has its target-dependent limit on how many elements can be in the vector type, so when it exceeds that just default to the usual (on-the- stack?) path for return values. * This part is probably harder, but make sure you can detect structs composed internally of those same static array types (and no more?), because then those can get the same treatment. End result is probably that LLVM codegen will pass a ton of that stuff around in registers, and when inlining you'll get a bunch of movaps and movups instructions to go away. -Mike --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "LDC - the LLVM D compiler" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/ldc-dev?hl=en -~----------~----~----~----~------~----~------~--~---
