On 9 October 2012 00:29, Iain Buclaw <span dir="ltr"><<a href="mailto:ibuclaw@ubuntu.com" target="_blank">ibuclaw@ubuntu.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On 8 October 2012 22:18, Manu <<a href="mailto:turkeyman@gmail.com">turkeyman@gmail.com</a>> wrote:<br>
> On 8 October 2012 23:05, Iain Buclaw <<a href="mailto:ibuclaw@ubuntu.com">ibuclaw@ubuntu.com</a>> wrote:<br>
>><br>
>> On 7 October 2012 13:12, Manu <<a href="mailto:turkeyman@gmail.com">turkeyman@gmail.com</a>> wrote:<br>
>> > On 5 October 2012 14:46, Iain Buclaw <<a href="mailto:ibuclaw@ubuntu.com">ibuclaw@ubuntu.com</a>> wrote:<br>
>> >><br>
>> >> On 5 October 2012 11:28, Manu <<a href="mailto:turkeyman@gmail.com">turkeyman@gmail.com</a>> wrote:<br>
>> >> > On 3 October 2012 16:40, Iain Buclaw <<a href="mailto:ibuclaw@ubuntu.com">ibuclaw@ubuntu.com</a>> wrote:<br>
>> >> >><br>
>> >> >> On 3 October 2012 02:31, jerro <<a href="mailto:a@a.com">a@a.com</a>> wrote:<br>
>> >> >> >> import core.simd, std.stdio;<br>
>> >> >> >><br>
>> >> >> >> void main()<br>
>> >> >> >> {<br>
>> >> >> >>   float4 a = 1, b = 2;<br>
>> >> >> >>   writeln((a + b).array); // WORKS: [3, 3, 3, 3]<br>
>> >> >> >><br>
>> >> >> >>   float4 c = [1, 2, 3, 4]; // ERROR: "Stored value type does<br>
>> >> >> >>                            // not match pointer operand type!"<br>
>> >> >> >>                            // [..a bunch of LLVM error code..]<br>
>> >> >> >><br>
>> >> >> >>   float4 c = 0, d = 1;<br>
>> >> >> >>   c.array[0] = 4;<br>
>> >> >> >>   c.ptr[1] = 4;<br>
>> >> >> >>   writeln((c + d).array); // WRONG: [1, 1, 1, 1]<br>
>> >> >> >> }<br>
>> >> >> ><br>
>> >> >> ><br>
>> >> >> > Oh, that doesn't work for me either. I never tried to use those,<br>
>> >> >> > so I<br>
>> >> >> > didn't<br>
>> >> >> > notice that before. This code gives me internal compiler errors<br>
>> >> >> > with<br>
>> >> >> > GDC<br>
>> >> >> > and<br>
>> >> >> > DMD too (with "float4 c = [1, 2, 3, 4]" commented out). I'm using<br>
>> >> >> > DMD<br>
>> >> >> > 2.060<br>
>> >> >> > and a recent versions of GDC and LDC on 64 bit Linux.<br>
>> >> >><br>
>> >> >> Then don't just talk about it, raise a bug - otherwise how do you<br>
>> >> >> expect it to get fixed!  ( <a href="http://www.gdcproject.org/bugzilla" target="_blank">http://www.gdcproject.org/bugzilla</a> )<br>
>> >> >><br>
>> >> >> I've made a note of the error you get with `__vector(float[4]) c =<br>
>> >> >> [1,2,3,4];' - That is because vector expressions implementation is<br>
>> >> >> very basic at the moment.  Look forward to hear from all your<br>
>> >> >> experiences so we can make vector support rock solid in GDC. ;-)<br>
>> >> ><br>
>> >> ><br>
>> >> > I didn't realise vector literals like that were supported properly in<br>
>> >> > the<br>
>> >> > front end yet?<br>
>> >> > Do they work at all? What does the code generated look like?<br>
>> >><br>
>> >> They get passed to the backend as of 2.060 - so looks like the<br>
>> >> semantic passes now allow them.<br>
>> >><br>
>> >> I've just recently added backend support in GDC -<br>
>> >><br>
>> >><br>
>> >> <a href="https://github.com/D-Programming-GDC/GDC/commit/7ada3d95b8af1b271d82f1ec5208f0b689eb143c#L1R1194" target="_blank">https://github.com/D-Programming-GDC/GDC/commit/7ada3d95b8af1b271d82f1ec5208f0b689eb143c#L1R1194</a><br>

>> >><br>
>> >> The codegen looks like so:<br>
>> >><br>
>> >> float4 a = 2;<br>
>> >> float4 b = [1,2,3,4];<br>
>> >><br>
>> >> ==><br>
>> >> vector(4) float a = { 2.0e+0, 2.0e+0, 2.0e+0, 2.0e+0 };<br>
>> >> vector(4) float b = { 1.0e+0, 2.0e+0, 3.0e+0, 4.0e+0 };<br>
>> >><br>
>> >> ==><br>
>> >>         movaps  .LC0, %xmm0<br>
>> >>         movaps  %xmm0, -24(%ebp)<br>
>> >>         movaps  .LC1, %xmm0<br>
>> >>         movaps  %xmm0, -40(%ebp)<br>
>> >><br>
>> >>         .align 16<br>
>> >> .LC0:<br>
>> >>         .long   1073741824<br>
>> >>         .long   1073741824<br>
>> >>         .long   1073741824<br>
>> >>         .long   1073741824<br>
>> >>         .align 16<br>
>> >> .LC1:<br>
>> >>         .long   1065353216<br>
>> >>         .long   1073741824<br>
>> >>         .long   1077936128<br>
>> >>         .long   1082130432<br>
>> ><br>
>> ><br>
>> > Perfect!<br>
>> > I can get on with my unittests :P<br>
>><br>
>> I fixed them again.<br>
>><br>
>><br>
>> <a href="https://github.com/D-Programming-GDC/GDC/commit/9402516e0b07031e841a15849f5dc94ae81dccdc#L4R1201" target="_blank">https://github.com/D-Programming-GDC/GDC/commit/9402516e0b07031e841a15849f5dc94ae81dccdc#L4R1201</a><br>

>><br>
>><br>
>> float a = 1, b = 2, c = 3, d = 4;<br>
>> float4 f = [a,b,c,d];<br>
>><br>
>> ===><br>
>>         movss   -16(%rbp), %xmm0<br>
>>         movss   -12(%rbp), %xmm1<br>
><br>
><br>
> Errr, that's not fixed...?<br>
> movss is not the opcode you're looking for.<br>
> Surely that should produce a single movaps...<br>
<br>
</div></div>I didn't say I compiled with optimisations - only -march=native.  =)<br></blockquote><div><br></div><div>Either way, that code is wrong. The prior code was correct (albeit with the redundant store, which I presume would have gone away with optimisation enabled)</div>
</div>