Does dmd have SSE intrinsics?

[Andrei Alexandrescu]

grauzone wrote:
> Robert Jacques wrote:
>> On Tue, 22 Sep 2009 12:32:25 -0400, Andrei Alexandrescu 
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>> Daniel Keep wrote:
>> [snip]
>>>>  The problem is that currently you have a class of types which can be
>>>> passed as arguments but cannot be returned.
>>>>  For example, Tango's Variant has this horrible hack where the ACTUAL
>>>> definition of Variant.get is:
>>>>      returnT!(S) get(S)();
>>>>  where you have:
>>>>      template returnT(T)
>>>>     {
>>>>         static if( isStaticArrayType!(T) )
>>>>             alias typeof(T.dup) returnT;
>>>>         else
>>>>             alias T returnT;
>>>>     }
>>>>  I can't recall the number of times this stupid hole in the language 
>>>> has
>>>> bitten me.  As for safety concerns, it's really no different to 
>>>> allowing
>>>> people to return delegates.  Not a very good reason, but I *REALLY* 
>>>> hate
>>>> having to special-case static arrays.
>>>
>>> Yah, same in std.variant. I think there it's called 
>>> DecayStaticToDynamicArray!T. Has someone added the correct handling 
>>> of static arrays to bugzilla? Walter wants to implement it, but we 
>>> want to make sure it's not forgotten.
>>
>> Well, what is the correct handling? Struct style RVO or delegate 
>> auto-magical heap allocation? Something else?
>>
>> Both solutions are far from perfect.
>> RVO breaks the reference semantics of arrays, though it works for many 
>> common cases and is high performance. This would be my choice, as I 
>> would like to efficiently return short vectors from functions.
>> Delegate style heap allocation runs into the whole 
>> I'd-rather-be-safe-than-sorry issue of excessive heap allocations. I'd 
>> imagine this would be better for generic code, since it would always 
>> work.
> 
> I think static arrays should be value types. Then this isn't a problem 
> anymore, and returning a static array can be handled exactly like 
> returning structs.
> 
> Didn't Walter once say that a type shouldn't behave differently, if it's 
> wrapped into a struct? With current static array semantics, this rule is 
> violated. If a static array has reference or value semantics kind of 
> depends, if it's inside a struct: if you copy a struct, the embedded 
> static array obviously looses its reference semantics.

Yah.

> Also, I second that it should be possible to declare void variables. 
> It'd be really useful for doing return value handling when transparently 
> wrapping delegate calls in generic code.

I think that already works.


Andrei