www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - LDC 0.11.0 Beta 3

reply "David Nadlinger" <code klickverbot.at> writes:
Here is the third round of beta packages for LDC 0.11.0. We are still =

missing a proper release announcement, but here is a quick overview of =

the most important facts:

  - Based on the DMD 2.062 frontend.
  - D1 is no longer supported.
  - The GC to stack promotion optimizer pass is enabled by default on =

-O2 and higher. Still *very* conservative, though, due to a change in =

the signature of the relevant druntime functions.
  - The LDC_global_crt_ctor/LDC_global_crt_dtor pragmas allow =

registering functions to be run during C runtime startup/shutdown. This =

is mostly helpful for implementing druntime itself.
  - The LDC_never_inline pragma can now be used to mark functions that =

should never be inlined.
  - As with recent versions of DMD, .di file generation now strips =

functions bodies. The '-Hkeep-all-bodies' command line has been added to =

disable this, like '-inline' does for DMD.
  - '-O' now is equivalent to '-O3' (instead of '-O2').
  - LDMD now correctly parses extra arguments for -run and no longer =

drops -deps.
  - Passing large static arrays by value no longer leads to horribly =

inefficient code and long compile times.
  - A large number of code generation bugs has been fixed, see the =

GitHub issue tracker [we are missing a nice overview].


Platform support
---
  - Linux x86/x86_64: Stable
  - OS X 10.7+: Stable (does *not* work on Snow Leopard and below)
  - Win32/MinGW: An alpha-quality version is available as part of this =

release. For use together with [1], see [2] for an overview of the =

current state.
  - Win64/MSVC: Not officially part of this release yet, a preview =

version is available here: =

http://forum.dlang.org/post/vscpokspiejlckivqsuq forum.dlang.org

For the current state on other platforms such as Linux/PPC64 and ARM, =

please refer to the LDC wiki. [3]


Package download
---

http://d32gngvpvl2pi1.cloudfront.net/ldc2-0.11.0-beta3-linux-x86.tar.gz
http://d32gngvpvl2pi1.cloudfront.net/ldc2-0.11.0-beta3-linux-x86.tar.xz
http://d32gngvpvl2pi1.cloudfront.net/ldc2-0.11.0-beta3-linux-x86_64.tar.g=
z
http://d32gngvpvl2pi1.cloudfront.net/ldc2-0.11.0-beta3-linux-x86_64.tar.x=
z
http://d32gngvpvl2pi1.cloudfront.net/ldc2-0.11.0-beta3-mingw-x86.7z
http://d32gngvpvl2pi1.cloudfront.net/ldc2-0.11.0-beta3-osx-x86_64.tar.gz
http://d32gngvpvl2pi1.cloudfront.net/ldc2-0.11.0-beta3-osx-x86_64.tar.xz
http://d32gngvpvl2pi1.cloudfront.net/ldc-0.11.0-beta3-src.tar.gz

MD5 checksums:

efc5863f6e5378849ff3d5b3b094bfc4  ldc2-0.11.0-beta3-linux-x86.tar.gz
36b78ff5d788a1eb1dc875910cd5fd25  ldc2-0.11.0-beta3-linux-x86.tar.xz
041679f78109876074c8cf11a151a2f2  ldc2-0.11.0-beta3-linux-x86_64.tar.gz
1768b0e4695256f6c18e908390edf2f2  ldc2-0.11.0-beta3-linux-x86_64.tar.xz
f70b31ae997bbf3d4505a26d1f5fa8ce  ldc2-0.11.0-beta3-mingw-x86.7z
fc0fe396d20a735b00c070c07da79906  ldc2-0.11.0-beta3-osx-x86_64.tar.gz
0fe50724975df55ee0e6b0094fc05acb  ldc2-0.11.0-beta3-osx-x86_64.tar.xz
e9d14e674a68a5ca688140e845105046  ldc-0.11.0-beta3-src.tar.gz


There are virtually no differences to beta 2, except for a tweak to how =

the build system locates LLVM, a cosmetic fix to the debug info compiler =

info field, and a few MinGW-specific fixes which were erroneously =

omitted from the last version.

If no unexpected major issues crop up, I'd propose to make this the =

final release (except for the file names, that is) =E2=80=93 in hindsight=
, I =

should have gone for "-rc1" instead of "-beta3". Any other regressions =

and big issues would be fixed in 0.11.1, which I hope we can release in =

another week or so. This upcoming release would also be built against =

LLVM 3.3 to work around the exception-related crashes on OS X (see =

below), and thus necessarily include the bool i1->i8 transition.

Sounds good?

  =E2=80=94 David



[1] =

http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%2=
0Win32/Personal%20Builds/rubenvb/gcc-4.8-dw2-release/i686-w64-mingw32-gcc=
-dw2-4.8.0-win32_rubenvb.7z/download
[2] http://klickverbot.at/blog/2013/05/the-state-of-ldc-on-windows/
[3] http://wiki.dlang.org/LDC
Jun 05 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
I am compiling some of my code with ldc2 on Windows, and I have 
found this, reduced:


import core.stdc.stdio: printf;
struct Foo {
     double[2] a;
}
auto foos = [Foo([0.0, 0.0]), Foo([10.0, 20.0])];
void main() {
     auto b1 = foos[0];
     auto b2 = foos[1];
     double[2] d = 0;
     d[] = b1.a[] - b2.a[];
     printf("%0.9f %0.9f\n", d[0], d[1]);
}



...>ldmd2 -run test.d
0.000000000 0.000000000

...>dmd -run test.d
-10.000000000 -20.000000000

I have found another bug that is less easy to reduce...

Bye,
bearophile
Jun 07 2013
next sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Friday, 7 June 2013 at 13:34:21 UTC, bearophile wrote:

 I am compiling some of my code with ldc2 on Windows, and I have 
 found this, reduced:


 import core.stdc.stdio: printf;
 struct Foo {
     double[2] a;
 }
 auto foos = [Foo([0.0, 0.0]), Foo([10.0, 20.0])];
 void main() {
     auto b1 = foos[0];
     auto b2 = foos[1];
     double[2] d = 0;
     d[] = b1.a[] - b2.a[];
     printf("%0.9f %0.9f\n", d[0], d[1]);
 }


Thanks for the report. Please post this to 
https://github.com/ldc-developers/ldc/issues though.

David
Jun 07 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
David Nadlinger:


 Thanks for the report. Please post this to 
 https://github.com/ldc-developers/ldc/issues though.


I am not registered on github :-(

Bye,
bearophile
Jun 07 2013
parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
W dniu 07.06.2013 15:56, bearophile pisze:

 David Nadlinger:


 Thanks for the report. Please post this to
 https://github.com/ldc-developers/ldc/issues though.


 I am not registered on github :-(


It will take 2 mins :-)


 Bye,
 bearophile
Jun 09 2013
prev sibling next sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Friday, 7 June 2013 at 13:34:21 UTC, bearophile wrote:

 I have found another bug that is less easy to reduce...


By the way, thanks for the great (!) test case.

David
Jun 07 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
I have not yet found a way to reduced the second bug I have 
found. I will try some more.

I think the list of compiler switches can be rationalized a bit, 
to make it more easy to understand for users.

How do I increase the stack size? With DMD I increase it adding 
something like -L/STACK:1000000 on the command line.

Is -O4 really performing Link-time optimization?

What about the culr (std.net.curl)? I presume the ones compiled 
for dmd are not good.

Bye,
bearophile
Jun 07 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
How do I disable and how I enable the "fast floating point math" 
in ldc2?

In GCC I use "-ffast-math" to enable it, and it's disable on 
default. It's enabled with -Ofast.

Bye and thank you,
bearophile
Jun 07 2013
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
 I have found another bug that is less easy to reduce...


I have localized it, it took some time:


import std.math: fmod;
import std.stdio: printf;
void main() {
     double r = fmod(2.3 + 3.0, 3.0);
     printf("%f\n", r);
}


...>dmd -run test.d
2.300000

...>ldmd2 -run test.d
0.000000

Bye,
bearophile
Jun 07 2013
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
 import std.math: fmod;
 import std.stdio: printf;
 void main() {
     double r = fmod(2.3 + 3.0, 3.0);
     printf("%f\n", r);
 }


And this works with ldc2:

import core.stdc.math: fmod;

Bye,
bearophile
Jun 07 2013
prev sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
Hi bearophile,

On Saturday, 8 June 2013 at 00:53:48 UTC, bearophile wrote:

 I have found another bug that is less easy to reduce...


 I have localized it, it took some time:


I just added the issues to the GitHub tracker, thanks again for 
the excellent reports.

Unfortunately, I pretty much won't be able to work on LDC at all 
during the next few weeks, but I am definitely going to look into 
the issues as soon as possible – if nobody else beats me to it, 
which I hope *will* happen.

David
Jun 19 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
David Nadlinger:


 I just added the issues to the GitHub tracker, thanks again for 
 the excellent reports.


You are welcome. Minutes ago I have added some SIMD-related bug 
reports in the D Bugzilla. I have also found two SIMD-related 
things that maybe are related just to LDC2.

---------------------------------

This seems a LDC2 bug:

LDC bug:


import core.simd: double2;
void main() {
     double2 x = [1.0, 2.0];
     double2 r1 = x + [1.0, 2.0];
     double2 r2 = [1.0, 2.0] + x;
}


LDC2 v.0.11.0 gives:

test.d(5): Error: cannot implicitly convert expression 
(cast(__vector(double[2u]))[1, 2] + x) of type double[] to 
__vector(double[2u])



import core.simd: double2;
void main() {
     double x = 1.0, y = 2.0;
     double2 a = [x, y];
     double2 sum = [0.0, 0.0];
     sum += [x, y] / a;
}


LDC2 v.0.11.0 gives:

test.d(6): Error: incompatible types for ((sum) += 
(cast(__vector(double[2u]))[x, y] / a)): '__vector(double[2u])' 
and 'double[]'

---------------------------------

And this seems a ldc2 performance bug worth fixing:


import core.simd: double2;
double foo(in double2 x) pure nothrow {
     return x.array[0] + x.array[1];
}
int main() {
     double2 x = [1.0, 2.0];
     return cast(int)foo(x);
}


LDC2 compiles "foo" to:

__D4temp3fooFNaNbxNhG2dZd:
     pushl   %ebp
     movl    %esp, %ebp
     andl    $-8, %esp
     subl    $8, %esp
     movapd  %xmm0, %xmm1
     unpckhpd    %xmm1, %xmm1
     addsd   %xmm0, %xmm1
     movsd   %xmm1, (%esp)
     fldl    (%esp)
     movl    %ebp, %esp
     popl    %ebp
     ret


But gcc compiles similar code (that uses __m128d instead of 
double2) using the instruction "haddpd", that I think is 
shorter/more efficient here.

(I don't know how dmd and gdc compile that program).

Bye,
bearophile
Jun 22 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
 But gcc compiles similar code (that uses __m128d instead of 
 double2) using the instruction "haddpd", that I think is 
 shorter/more efficient here.


C code:


#include <emmintrin.h>
double foo(const __m128d x) {
     return x[0] + x[1];
}
int main() {
     __m128d x = _mm_set_pd(1.0, 2.0);
     return (int)foo(x);
}


Compiled with:

gcc -S -Ofast -fomit-frame-pointer -march=native -mfpmath=sse 
-msse2 test.c -o test.s

GCC version 4.8.0

The asm of "foo":

_foo:
     subl    $20, %esp
     haddpd  %xmm0, %xmm0
     movsd   %xmm0, (%esp)
     fldl    (%esp)
     addl    $20, %esp
     ret


Bye,
bearophile
Jun 22 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
 _foo:
     subl    $20, %esp
     haddpd  %xmm0, %xmm0
     movsd   %xmm0, (%esp)
     fldl    (%esp)
     addl    $20, %esp
     ret


A discussion on the #llvm IRC channel seems to show that's a llvm 
fault, so this is not a bug report for ldc2. Only the other is 
valid for ldc2.

Bye,
bearophile
Jun 22 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Another test case:


import core.simd: double2;
struct Foo {
     double2 x;
     this(uint) {
         x = [0.0, 0.0];
     }
}
void main() {
     Foo y = Foo();
}


ldmd2 gives:

fpext source and destination must both be a vector or neither
   %tmp1 = fpext double 0x7FFC000000000000 to <2 x double>
Broken module found, compilation aborted!

Bye,
bearophile
Jun 27 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
int main() {
     import core.simd;
     float[16] a = 1.0;
     float4 t = 0, k = 2;
     auto b = cast(float4[])a;
     for (size_t i = 0; i < b.length; i++)
         t += b[i] * k;
     return cast(int)t.array[2];
}



Compiling it with "ldmd2 -O":

Error: Instruction does not dominate all uses!
   %tmp33.Elt = fmul float %tmp33.Elt.lhs, 2.000000e+00
   %1 = fadd float %0, %tmp33.Elt
Instruction does not dominate all uses!
   %tmp31 = load <4 x float>* %tmp30, align 16
   %tmp33.Elt.lhs = extractelement <4 x float> %tmp31, i32 2
Broken module found, compilation terminated.
Broken module found, compilation terminated.
Broken module found, compilation terminated.

Bye,
bearophile
Jun 29 2013
parent reply "Kai Nacke" <kai redstar.de> writes:
On Sunday, 30 June 2013 at 01:52:46 UTC, bearophile wrote:

 int main() {
     import core.simd;
     float[16] a = 1.0;
     float4 t = 0, k = 2;
     auto b = cast(float4[])a;
     for (size_t i = 0; i < b.length; i++)
         t += b[i] * k;
     return cast(int)t.array[2];
 }



 Compiling it with "ldmd2 -O":

 Error: Instruction does not dominate all uses!
   %tmp33.Elt = fmul float %tmp33.Elt.lhs, 2.000000e+00
   %1 = fadd float %0, %tmp33.Elt
 Instruction does not dominate all uses!
   %tmp31 = load <4 x float>* %tmp30, align 16
   %tmp33.Elt.lhs = extractelement <4 x float> %tmp31, i32 2
 Broken module found, compilation terminated.
 Broken module found, compilation terminated.
 Broken module found, compilation terminated.

 Bye,
 bearophile


Thanks for the nice test case.

It looks like a LLVM 3.3 problem. I can reproduce it with LDC 
head and LLVM 3.3, but not with LLVM trunk or LLVM 3.2. I will 
further investigate it..

Kai
Jun 30 2013
parent "Kai Nacke" <kai redstar.de> writes:
On Sunday, 30 June 2013 at 17:10:38 UTC, Kai Nacke wrote:

 On Sunday, 30 June 2013 at 01:52:46 UTC, bearophile wrote:

 int main() {
    import core.simd;
    float[16] a = 1.0;
    float4 t = 0, k = 2;
    auto b = cast(float4[])a;
    for (size_t i = 0; i < b.length; i++)
        t += b[i] * k;
    return cast(int)t.array[2];
 }



 Compiling it with "ldmd2 -O":

 Error: Instruction does not dominate all uses!
  %tmp33.Elt = fmul float %tmp33.Elt.lhs, 2.000000e+00
  %1 = fadd float %0, %tmp33.Elt
 Instruction does not dominate all uses!
  %tmp31 = load <4 x float>* %tmp30, align 16
  %tmp33.Elt.lhs = extractelement <4 x float> %tmp31, i32 2
 Broken module found, compilation terminated.
 Broken module found, compilation terminated.
 Broken module found, compilation terminated.

 Bye,
 bearophile


 Thanks for the nice test case.

 It looks like a LLVM 3.3 problem. I can reproduce it with LDC 
 head and LLVM 3.3, but not with LLVM trunk or LLVM 3.2. I will 
 further investigate it..

 Kai
Jun 30 2013
prev sibling parent reply "Kai Nacke" <kai redstar.de> writes:
On Thursday, 27 June 2013 at 20:00:47 UTC, bearophile wrote:

 Another test case:


 import core.simd: double2;
 struct Foo {
     double2 x;
     this(uint) {
         x = [0.0, 0.0];
     }
 }
 void main() {
     Foo y = Foo();
 }


 ldmd2 gives:

 fpext source and destination must both be a vector or neither
   %tmp1 = fpext double 0x7FFC000000000000 to <2 x double>
 Broken module found, compilation aborted!

 Bye,
 bearophile


Thanks for the nice test case. I can reproduce it with LDC head 


Kai
Jun 30 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Kai:


 Thanks for the nice test case. I can reproduce it with LDC head 



You are welcome. Have you also seen the two cases above?

import core.simd: double2;
void main() {
     double2 x = [1.0, 2.0];
     double2 r1 = x + [1.0, 2.0];
     double2 r2 = [1.0, 2.0] + x;
}


import core.simd: double2;
void main() {
     double x = 1.0, y = 2.0;
     double2 a = [x, y];
     double2 sum = [0.0, 0.0];
     sum += [x, y] / a;
}


Bye,
bearophile
Jun 30 2013
parent reply "Kai Nacke" <kai redstar.de> writes:
On Sunday, 30 June 2013 at 17:25:50 UTC, bearophile wrote:

 Kai:


 Thanks for the nice test case. I can reproduce it with LDC 



 You are welcome. Have you also seen the two cases above?

 import core.simd: double2;
 void main() {
     double2 x = [1.0, 2.0];
     double2 r1 = x + [1.0, 2.0];
     double2 r2 = [1.0, 2.0] + x;
 }


 import core.simd: double2;
 void main() {
     double x = 1.0, y = 2.0;
     double2 a = [x, y];
     double2 sum = [0.0, 0.0];
     sum += [x, y] / a;
 }


 Bye,
 bearophile


Thanks for the hint. I am still scanning the thread and try to 
reproduce the failures.

Kai
Jun 30 2013
parent reply "Kai Nacke" <kai redstar.de> writes:
On Sunday, 30 June 2013 at 17:28:12 UTC, Kai Nacke wrote:

 On Sunday, 30 June 2013 at 17:25:50 UTC, bearophile wrote:

 Kai:


 Thanks for the nice test case. I can reproduce it with LDC 



 You are welcome. Have you also seen the two cases above?

 import core.simd: double2;
 void main() {
    double2 x = [1.0, 2.0];
    double2 r1 = x + [1.0, 2.0];
    double2 r2 = [1.0, 2.0] + x;
 }


 import core.simd: double2;
 void main() {
    double x = 1.0, y = 2.0;
    double2 a = [x, y];
    double2 sum = [0.0, 0.0];
    sum += [x, y] / a;
 }


 Bye,
 bearophile


 Thanks for the hint. I am still scanning the thread and try to 
 reproduce the failures.

 Kai


I could not reproduce both failures with LDC head. Maybe it is a 
2.062 related problem?
Jul 02 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
Kai Nacke:


 I could not reproduce both failures with LDC head. Maybe it is 
 a 2.062 related problem?


I have just taken and installed the latest version, ldc2 on 
Windows 32 bit (Vista) (LDC - the LLVM D compiler (0.11.0) based 
on DMD v2.062 and LLVM 3.3svn)):
http://d32gngvpvl2pi1.cloudfront.net/ldc2-0.11.0-mingw-x86.7z

I compile with just:
ldc2 temp.d

And both those programs give the errors :-(

test.d(5): Error: cannot implicitly convert expression 
(cast(__vector(double[2u]))[1, 2] + x) of type double[] to 
__vector(double[2u])

test.d(6): Error: incompatible types for ((sum) += 
(cast(__vector(double[2u]))[x, y] / a)): '__vector(double[2u])' 
and 'double[]'

I am using the MinGW in the link given by David Nadlinger (gcc 
version 4.8.0 (rubenvb-4.8.0)):

http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/gcc-4.8-dw2-release/i686-w64-mingw32-gcc-dw2-4.8.0-win32_rubenvb.7z/download

Maybe it's a 2.062 problem, I don't know. But while compiling dmd 
is a breeze, I don't think I want to compile ldc2 myself. If you 
think this problem is missing in the ldc2 2.063 then let's ignore 
this problem until the ldc2 2.063 binary has being released and I 
can test it again :-)

Bye,
bearophile
Jul 02 2013