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