www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - LDC 0.12.0 beta 1 released, please help test!

reply David Nadlinger <code klickverbot.at> writes:
(Almost) all the issues reported against the first 0.12.0 alpha
release have been fixed, so it is time for the next round of testing.
Like for alpha 1, please refer to the GitHub release page for the
download links and the
preliminary change log:

https://github.com/ldc-developers/ldc/releases/tag/v0.12.0-beta1

Some of the issues necessitate major changes to the internal workings
of LDC, so please be sure to test the beta against your projects, even
if 0.12.0-alpha1 already worked fine.

MD5 checksums:

4497254aeb0dffd05cfe052b063ae576  ldc2-0.12.0-beta1-linux-x86.tar.gz
918d8c49a33c726638dd1c9bf3126be1  ldc2-0.12.0-beta1-linux-x86.tar.xz
8d065ca9bb510b67e930fda3541abc44  ldc2-0.12.0-beta1-linux-x86_64.tar.gz
4d34bc5616caffcd097107ac89b8f58a  ldc2-0.12.0-beta1-linux-x86_64.tar.xz
9351ae4804a9bc5fe0a0a0817c50002a  ldc2-0.12.0-beta1-mingw-x86.7z
2fd70362b1ea0a63830acafe8c3615c0  ldc2-0.12.0-beta1-mingw-x86.zip
7ea39c8514f41b4cbd9144dbbeb4a29f  ldc2-0.12.0-beta1-osx-x86_64.tar.gz
b6ca20e3acb17e02f7780f34e7700d23  ldc2-0.12.0-beta1-osx-x86_64.tar.xz
75f8f14d77e98f8694811be801fba3e6  ldc-0.12.0-beta1.tar.gz

As always, the Win32/MinGW packages require a recent version of the
mingw-w64 toolchain, see the (new) README file for details. There are
no packages for the Win64/MSVC port yet.

Please be sure to report any regressions at
https://github.com/ldc-developers/ldc/issues!

Cheers,
David
Oct 15 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
David Nadlinger:

 (Almost) all the issues reported against the first 0.12.0 alpha
 release have been fixed, so it is time for the next round of 
 testing.
I am now testing this ldc2 on Windows. I have also seen this thread: http://forum.dlang.org/thread/CAP9J_HXfC736D452phSFBuOsoWtiRZ=Qsx-4eiGtwG-E76EMnA mail.gmail.com This is a small test program: import std.algorithm: count; int foo(int[] data) { return data.count([0, 1]); } void main() {} This ldc2 compiles it to (32 bit code): __D4test3fooFAiZi: pushl %ebp pushl %ebx pushl %edi pushl %esi subl $24, %esp movl $2, 4(%esp) movl $__D11TypeInfo_Ai6__initZ, (%esp) calll __d_newarrayvT movl %eax, %esi movl %edx, %ebx movl $1, 4(%ebx) movl $0, (%ebx) movl 48(%esp), %ebp movl 44(%esp), %edi testl %esi, %esi jne LBB0_2 movl $_.str5, 16(%esp) movl $58, 12(%esp) movl $5699, 8(%esp) movl $_.str4, 4(%esp) movl $42, (%esp) calll __D3std9exception7bailOutFNaNfAyakxAaZv subl $20, %esp LBB0_2: movl %ebp, 12(%esp) movl %edi, 8(%esp) movl %ebx, 4(%esp) movl %ebx, 20(%esp) movl %esi, (%esp) xorl %ebx, %ebx calll __D3std9algorithm34__T4findVAyaa6_61203d3d2062TAiTAiZ4findFNaNbNfAiAiZAi subl $16, %esp testl %eax, %eax je LBB0_5 testl %esi, %esi je LBB0_5 .align 16, 0x90 LBB0_4: movl 20(%esp), %ecx movl %ecx, 4(%esp) movl %esi, (%esp) movl %edi, %ecx subl %eax, %ecx addl %esi, %ecx leal (%ebp,%ecx,4), %ebp movl %ebp, 12(%esp) subl %ecx, %edi movl %edi, 8(%esp) incl %ebx calll __D3std9algorithm34__T4findVAyaa6_61203d3d2062TAiTAiZ4findFNaNbNfAiAiZAi subl $16, %esp testl %eax, %eax jne LBB0_4 LBB0_5: movl %ebx, %eax addl $24, %esp popl %esi popl %edi popl %ebx popl %ebp ret $8 As you see there's a call to __d_newarrayvT. But perhaps that call can be optimized away by a good compiler, allocating the [0, 1] array statically, something like this: import std.algorithm: count; int foo(int[] data) { return data.count([0, 1]); } void main() {} import std.algorithm: count; int foo(int[] data) { static int[2] tmp = [0, 1]; return data.count(tmp[]); } void main() {} That ldc2 compiler better to: __D5test23fooFAiZi: pushl %ebp pushl %ebx pushl %edi pushl %esi subl $40, %esp movl 64(%esp), %esi movl 60(%esp), %edx cmpl $2, %edx jb LBB0_4 movl __tls_index, %eax movl %fs:44, %ecx movl (%ecx,%eax,4), %ecx movl __D5test23fooFAiZi3tmpG2i SECREL32+4(%ecx), %edi movl %edi, 36(%esp) movl $1, %eax cmpl %edi, __D5test23fooFAiZi3tmpG2i SECREL32(%ecx) movl $1, %ebx je LBB0_3 movl $2, %ebx LBB0_3: movl %ebx, 32(%esp) cmpl $1, %edx jbe LBB0_4 .align 16, 0x90 LBB0_9: movl %eax, %ebp movl $1, %eax movl 36(%esp), %ecx cmpl %ecx, (%esi,%ebp,4) jne LBB0_12 leal -1(%ebp), %eax movl %edx, %edi subl %eax, %edi movl %ebx, %eax je LBB0_12 leal -4(%esi,%ebp,4), %eax movl %eax, 4(%esp) movl __tls_index, %eax movl %fs:44, %ecx movl (%ecx,%eax,4), %eax leal __D5test23fooFAiZi3tmpG2i SECREL32(%eax), %eax movl %eax, 12(%esp) movl $__D11TypeInfo_Ai6__initZ, 16(%esp) movl $1, 8(%esp) movl $1, (%esp) movl %esi, %ebx movl %edx, %esi calll __adEq2 movl %esi, %edx movl %ebx, %esi movl 32(%esp), %ebx testl %eax, %eax movl %ebx, %eax jne LBB0_5 LBB0_12: addl %ebp, %eax cmpl %edx, %eax jb LBB0_9 LBB0_4: xorl %edi, %edi LBB0_5: movl $0, 20(%esp) testl %edi, %edi je LBB0_23 movl __tls_index, %eax movl %fs:44, %ecx movl (%ecx,%eax,4), %eax movl __D5test23fooFAiZi3tmpG2i SECREL32+4(%eax), %eax movl %eax, 32(%esp) movl $0, 20(%esp) jmp LBB0_7 LBB0_21: movl 28(%esp), %edi jmp LBB0_22 .align 16, 0x90 LBB0_7: movl %esi, %ebp movl %edx, %esi subl %edi, %esi leal 8(%ebp,%esi,4), %eax movl %eax, 24(%esp) addl $2, %esi subl %esi, %edx incl 20(%esp) cmpl $2, %edx jae LBB0_13 xorl %edi, %edi jmp LBB0_22 .align 16, 0x90 LBB0_13: movl __tls_index, %eax movl %fs:44, %ecx movl (%ecx,%eax,4), %ecx movl $1, %eax movl 32(%esp), %edi cmpl %edi, __D5test23fooFAiZi3tmpG2i SECREL32(%ecx) movl $1, 36(%esp) je LBB0_15 movl $2, 36(%esp) LBB0_15: cmpl $1, %edx jbe LBB0_16 .align 16, 0x90 LBB0_17: movl %eax, %ebx leal (%ebx,%esi), %ecx movl $1, %eax movl 32(%esp), %edi cmpl %edi, (%ebp,%ecx,4) jne LBB0_20 leal -1(%ebx), %eax movl %edx, %ecx subl %eax, %ecx movl %ecx, 28(%esp) movl 36(%esp), %eax je LBB0_20 leal -1(%ebx,%esi), %eax leal (%ebp,%eax,4), %eax movl %eax, 4(%esp) movl __tls_index, %eax movl %fs:44, %ecx movl (%ecx,%eax,4), %eax leal __D5test23fooFAiZi3tmpG2i SECREL32(%eax), %eax movl %eax, 12(%esp) movl $__D11TypeInfo_Ai6__initZ, 16(%esp) movl $1, 8(%esp) movl $1, (%esp) movl %esi, %edi movl %ebp, %esi movl %edx, %ebp calll __adEq2 movl %ebp, %edx movl %esi, %ebp movl %edi, %esi testl %eax, %eax movl 36(%esp), %eax jne LBB0_21 LBB0_20: addl %ebx, %eax cmpl %edx, %eax jb LBB0_17 LBB0_16: xorl %edi, %edi LBB0_22: testl %edi, %edi movl 24(%esp), %esi jne LBB0_7 LBB0_23: movl 20(%esp), %eax addl $40, %esp popl %esi popl %edi popl %ebx popl %ebp ret $8 (I don't know what __D5test23fooFAiZi3tmpG2i SECREL32 is). Now what's left to remove are two calls to __adEq2 (because I think they are used only on length-2 arrays and much slower and an inlined test of length and two ints equality). So can ldc2 remove this call to __d_newarrayvT and later even to __adEq2? Bye, bearophile
Oct 15 2013
parent reply David Nadlinger <code klickverbot.at> writes:
On Tue, Oct 15, 2013 at 11:16 PM, bearophile <bearophileHUGS lycos.com> wrote:
 As you see there's a call to __d_newarrayvT. But perhaps that call can be
 optimized away by a good compiler, allocating the [0, 1] array statically,
 something like this:


 import std.algorithm: count;
 int foo(int[] data) {
     return data.count([0, 1]);
 }
 void main() {}



 import std.algorithm: count;
 int foo(int[] data) {
     static int[2] tmp = [0, 1];
     return data.count(tmp[]);
 }
 void main() {}
The problem is that for this optimization to be valid, the compiler has to be able to infer that count can escape no references to the array. And unless everything is inlined (as shown in the assembly, the embedded find call is currently not), LDC can't do this right now. Ideally, we'd be able to take advantage of purity for that, but it isn't that easy to actually implement this.
 (I don't know what __D5test23fooFAiZi3tmpG2i SECREL32 is).
It's part of the codegen for TLS variables on Windows ( SECREL32 it gives the offset of the symbol to the beginning of the section, which is used to index the global TLS array). Make the static array immutable/__gshared for more efficient codegen.
 Now what's left to remove are two calls to __adEq2 (because I think they are
 used only on length-2 arrays and much slower and an inlined test of length
 and two ints equality).
IIRC the 2 in the name bears no relationship to the length of the arrays. If we statically know that the array types match and that the members are POD types (in the sense of no overloaded equality operator), inlining the comparison would indeed be much faster, and would avoid messing around with TypeInfo altogether. Could you add an enhancement request for that? Actually, could you maybe just add the whole example to the GitHub tracker for inspiration for future optimization work? David
Oct 23 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
David Nadlinger:

If we statically know that the array types match and
 that the
 members are POD types (in the sense of no overloaded equality
 operator), inlining the comparison would indeed be much faster, 
 and
 would avoid messing around with TypeInfo altogether. Could you 
 add an
 enhancement request for that?
Do you mean an DMD enhancement request in Bugzilla? Perhaps this is an optimization for the front-end. Bye, bearophile
Oct 23 2013
parent David Nadlinger <code klickverbot.at> writes:
On Wed, Oct 23, 2013 at 8:50 PM, bearophile <bearophileHUGS lycos.com> wrote:
 Do you mean an DMD enhancement request in Bugzilla? Perhaps this is an
 optimization for the front-end.
No, I think this would need to be fixed in the glue layer, so https://github.com/ldc-developers/ldc/issues would be the place to go. David
Oct 23 2013
prev sibling next sibling parent reply "Andrea Fontana" <nospam example.com> writes:
Is there any (un)official (beta-)repository for ubuntu to keep it 
updated?

On Tuesday, 15 October 2013 at 17:48:36 UTC, David Nadlinger 
wrote:
 (Almost) all the issues reported against the first 0.12.0 alpha
 release have been fixed, so it is time for the next round of 
 testing.
 Like for alpha 1, please refer to the GitHub release page for 
 the
 download links and the
 preliminary change log:

 https://github.com/ldc-developers/ldc/releases/tag/v0.12.0-beta1

 Some of the issues necessitate major changes to the internal 
 workings
 of LDC, so please be sure to test the beta against your 
 projects, even
 if 0.12.0-alpha1 already worked fine.

 MD5 checksums:

 4497254aeb0dffd05cfe052b063ae576  
 ldc2-0.12.0-beta1-linux-x86.tar.gz
 918d8c49a33c726638dd1c9bf3126be1  
 ldc2-0.12.0-beta1-linux-x86.tar.xz
 8d065ca9bb510b67e930fda3541abc44  
 ldc2-0.12.0-beta1-linux-x86_64.tar.gz
 4d34bc5616caffcd097107ac89b8f58a  
 ldc2-0.12.0-beta1-linux-x86_64.tar.xz
 9351ae4804a9bc5fe0a0a0817c50002a  ldc2-0.12.0-beta1-mingw-x86.7z
 2fd70362b1ea0a63830acafe8c3615c0  
 ldc2-0.12.0-beta1-mingw-x86.zip
 7ea39c8514f41b4cbd9144dbbeb4a29f  
 ldc2-0.12.0-beta1-osx-x86_64.tar.gz
 b6ca20e3acb17e02f7780f34e7700d23  
 ldc2-0.12.0-beta1-osx-x86_64.tar.xz
 75f8f14d77e98f8694811be801fba3e6  ldc-0.12.0-beta1.tar.gz

 As always, the Win32/MinGW packages require a recent version of 
 the
 mingw-w64 toolchain, see the (new) README file for details. 
 There are
 no packages for the Win64/MSVC port yet.

 Please be sure to report any regressions at
 https://github.com/ldc-developers/ldc/issues!

 Cheers,
 David
Oct 16 2013
parent reply "David Nadlinger" <code klickverbot.at> writes:
Hi Andrea,

On 16 Oct 2013, at 15:35, Andrea Fontana wrote:
 Is there any (un)official (beta-)repository for ubuntu to keep it 
 updated?
I agree that this would be a very nice thing to have. But as far as I know, there aren't any at least somewhat recent LDC packages for Debian/Ubuntu at all. That is, unless somebody actually started to maintain ones without actually announcing this on the LDC mailing lists. We really need to get this situation resolved; it's a shame not to have a recent version of LDC in the Debian/Ubuntu distro repositories… Cheers, David
Oct 16 2013
parent "Dicebot" <public dicebot.lv> writes:
Why not simply add to http://d-apt.sourceforge.net ?
Oct 16 2013
prev sibling next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Tuesday, 15 October 2013 at 17:48:36 UTC, David Nadlinger 
wrote:
 (Almost) all the issues reported against the first 0.12.0 alpha
 release have been fixed, so it is time for the next round of 
 testing.
 Like for alpha 1, please refer to the GitHub release page for 
 the
 download links and the
 preliminary change log:

 https://github.com/ldc-developers/ldc/releases/tag/v0.12.0-beta1

 Some of the issues necessitate major changes to the internal 
 workings
 of LDC, so please be sure to test the beta against your 
 projects, even
 if 0.12.0-alpha1 already worked fine.

 MD5 checksums:

 4497254aeb0dffd05cfe052b063ae576  
 ldc2-0.12.0-beta1-linux-x86.tar.gz
 918d8c49a33c726638dd1c9bf3126be1  
 ldc2-0.12.0-beta1-linux-x86.tar.xz
 8d065ca9bb510b67e930fda3541abc44  
 ldc2-0.12.0-beta1-linux-x86_64.tar.gz
 4d34bc5616caffcd097107ac89b8f58a  
 ldc2-0.12.0-beta1-linux-x86_64.tar.xz
 9351ae4804a9bc5fe0a0a0817c50002a  ldc2-0.12.0-beta1-mingw-x86.7z
 2fd70362b1ea0a63830acafe8c3615c0  
 ldc2-0.12.0-beta1-mingw-x86.zip
 7ea39c8514f41b4cbd9144dbbeb4a29f  
 ldc2-0.12.0-beta1-osx-x86_64.tar.gz
 b6ca20e3acb17e02f7780f34e7700d23  
 ldc2-0.12.0-beta1-osx-x86_64.tar.xz
 75f8f14d77e98f8694811be801fba3e6  ldc-0.12.0-beta1.tar.gz

 As always, the Win32/MinGW packages require a recent version of 
 the
 mingw-w64 toolchain, see the (new) README file for details. 
 There are
 no packages for the Win64/MSVC port yet.

 Please be sure to report any regressions at
 https://github.com/ldc-developers/ldc/issues!

 Cheers,
 David
Tested out a few very simple programs on Windows. Worked well.
Oct 16 2013
parent David Nadlinger <code klickverbot.at> writes:
On Wed, Oct 16, 2013 at 10:38 PM, Brad Anderson <eco gnuk.net> wrote:
 Tested out a few very simple programs on Windows.  Worked well.
Thanks for the feedback. One of the downsides of using the new GitHub Releases feature for hosting the downloads is that there doesn't seem to way to get the statistics, so we have no way of knowing how many people actually tested the beta already. Cheers, David
Oct 17 2013
prev sibling parent reply "dnewbie" <run3 myopera.com> writes:
ldc2 -c my.d -of=my.o
Output: 'my.obj'.

ldc2 -lib my.d -of=libmy.a
Output: 'liblibmy.a.lib'
Oct 17 2013
parent David Nadlinger <code klickverbot.at> writes:
On Thu, Oct 17, 2013 at 11:33 PM, dnewbie <run3 myopera.com> wrote:
 ldc2 -c my.d -of=my.o
 Output: 'my.obj'.

 ldc2 -lib my.d -of=libmy.a
 Output: 'liblibmy.a.lib'
I take it this is on Windows? In any case, could you please report the issue on the GitHub issue tracker? The output file determination logic is not easy, because it has to handle writing multiple files (e.g. .bc and .o) at the same time, but this definitely should not happen. David
Oct 20 2013