www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - ldc 0.9.1 released

reply Christian Kamm <kamm-incasoftware removethis.de> writes:
The release 0.9.1 of LDC, the LLVM based compiler for the D programming 
language, contains the following major improvements:

 * lots of bug fixes (http://www.dsource.org/projects/ldc/report/15)
 * x86-64 support is mature
 * inline asm improved (we now define D_Inline_Asm)
 * cross-compilation support
 * uses boehm-gc during compilation (x86-32 only)
 * D specific optimizations:
   * turn GC allocations to allocas if possible
   * simplify or remove certain calls to D runtime functions

The command line interface of LDC now has added options in line with other 
LLVM based tools. Please use the ldmd wrapper if you want a drop-in 
replacement for DMD.

Linux x86-32 download: 
http://www.incasoftware.de/~kamm/ldc/ldc-0.9.1-x86_32.tar.bz2

Linux x86-64 download: 
http://www.incasoftware.de/~kamm/ldc/ldc-0.9.1-x86_64.tar.bz2

Tomas Lindquist Olsen
Christian Kamm
Frits van Bommel
Kelly Wilson
May 27 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Christian Kamm wrote:

 The release 0.9.1 of LDC, the LLVM based compiler for the D programming 
 language, contains the following major improvements:
 
  * lots of bug fixes (http://www.dsource.org/projects/ldc/report/15)
  * x86-64 support is mature
  * inline asm improved (we now define D_Inline_Asm)
  * cross-compilation support
  * uses boehm-gc during compilation (x86-32 only)
  * D specific optimizations:
    * turn GC allocations to allocas if possible
    * simplify or remove certain calls to D runtime functions
 
 The command line interface of LDC now has added options in line with other 
 LLVM based tools. Please use the ldmd wrapper if you want a drop-in 
 replacement for DMD.
 
 Linux x86-32 download: 
 http://www.incasoftware.de/~kamm/ldc/ldc-0.9.1-x86_32.tar.bz2
 
 Linux x86-64 download: 
 http://www.incasoftware.de/~kamm/ldc/ldc-0.9.1-x86_64.tar.bz2
 
 Tomas Lindquist Olsen
 Christian Kamm
 Frits van Bommel
 Kelly Wilson


Great! Quick question - are you supporting or considering supporting D2? 
I looked on the project's home page and couldn't find that information. 
There's mention of druntime for D2 which makes me hopeful.

Thanks,

Andrei
May 27 2009
parent reply Robert Clipsham <robert octarineparrot.com> writes:
Andrei Alexandrescu wrote:

 Great! Quick question - are you supporting or considering supporting D2? 
 I looked on the project's home page and couldn't find that information. 
 There's mention of druntime for D2 which makes me hopeful.
 
 Thanks,
 
 Andrei


D2 support in LDC has been started, but it does not have any of D2's 
features implemented. I believe all that has been done is the frontend 
added. Last time I checked ldc + d2 would not compile.

I believe that the plan is to make D1 solid (more so than DMD), before 
moving on to D2. One of the developers might be able to give a more 
accurate status.
May 27 2009
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Robert Clipsham wrote:

 Andrei Alexandrescu wrote:

 Great! Quick question - are you supporting or considering supporting 
 D2? I looked on the project's home page and couldn't find that 
 information. There's mention of druntime for D2 which makes me hopeful.

 Thanks,

 Andrei


 
 D2 support in LDC has been started, but it does not have any of D2's 
 features implemented. I believe all that has been done is the frontend 
 added. Last time I checked ldc + d2 would not compile.
 
 I believe that the plan is to make D1 solid (more so than DMD), before 
 moving on to D2. One of the developers might be able to give a more 
 accurate status.


That's pretty accurate, actually.

A while back somebody sent in a patch to get D2 support working, but by the
time 
it got properly reviewed it was already outdated...

The main problem on this front is that nobody currently working on LDC is 
particularly interested in D2.
May 27 2009
next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
Frits van Bommel wrote:

 Robert Clipsham wrote:

 Andrei Alexandrescu wrote:

 Great! Quick question - are you supporting or considering supporting 
 D2? I looked on the project's home page and couldn't find that 
 information. There's mention of druntime for D2 which makes me hopeful.

 Thanks,

 Andrei


 D2 support in LDC has been started, but it does not have any of D2's 
 features implemented. I believe all that has been done is the frontend 
 added. Last time I checked ldc + d2 would not compile.

 I believe that the plan is to make D1 solid (more so than DMD), before 
 moving on to D2. One of the developers might be able to give a more 
 accurate status.


 
 That's pretty accurate, actually.
 
 A while back somebody sent in a patch to get D2 support working, but by 
 the time it got properly reviewed it was already outdated...
 
 The main problem on this front is that nobody currently working on LDC 
 is particularly interested in D2.


I actually thought about giving this a try about a week ago. I managed 
to get all but one file to compile with the current version of the D2 
front end (2.021 I believe)... Not bad considering my (lack of) C/C++ 
knowledge. If there's some interest for it I suppose I could give it 
another shot and try to merge the latest front end, it'd be a good 
chance for me to finally learn C/C++ (I made the <del>mistake</del> 
decision to learn D first... I found it too awesome to bother learning 
the obviously inferior C/C++ :P).
May 27 2009
next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Robert Clipsham wrote:
...

 I actually thought about giving this a try about a week ago. I managed 
 to get all but one file to compile with the current version of the D2 
 front end (2.021 I believe)... Not bad considering my (lack of) C/C++ 
 knowledge. If there's some interest for it I suppose I could give it 
 another shot and try to merge the latest front end, it'd be a good 
 chance for me to finally learn C/C++ (I made the <del>mistake</del> 
 decision to learn D first... I found it too awesome to bother learning 
 the obviously inferior C/C++ :P).


I'm interested, for sure.
May 27 2009
prev sibling parent reply Kagamin <spam here.lot> writes:
Robert Clipsham Wrote:


 Not bad considering my (lack of) C/C++ 
 knowledge. If there's some interest for it I suppose I could give it 
 another shot and try to merge the latest front end, it'd be a good 
 chance for me to finally learn C/C++ (I made the <del>mistake</del> 
 decision to learn D first... I found it too awesome to bother learning 
 the obviously inferior C/C++ :P).


I found recently that properly designed C++ code can live happily without all
that esoteric macro/template crap and can be pretty readable and understandable
even using nasty antipatterns. This being achieved simply by using C++ subset
that is supported on various platforms. Code that does the job instead of
casting black magic.
May 28 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Kagamin wrote:

 I found recently that properly designed C++ code can live happily
 without all that esoteric macro/template crap and can be pretty
 readable and understandable even using nasty antipatterns. This being
 achieved simply by using C++ subset that is supported on various
 platforms. Code that does the job instead of casting black magic.


The D compiler source doesn't use any templates, rtti, or clever macro 
hacks. Whether it's well designed or not, I'll let others decide. It is 
written in a "D-ish" style.
May 28 2009
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Walter Bright wrote:

 The D compiler source doesn't use any templates, rtti, or clever macro 
 hacks. Whether it's well designed or not, I'll let others decide. It is 
 written in a "D-ish" style.


I ported part of the DMDFE to Java, and found it quite well-designed 
(with the exception of the frequent use of globals). The gotos make it 
more readable IMO (compare the original to the Java version where gotos 
are replaced with exceptions, replaced with duplicated code, emulated 
with a bunch of booleans, or refactored into separate functions taking 
7+ arguments).

However, the DMDFE's organization relies on being able to declare class 
member functions separately from where they're defined, which is 
impossible in D (hint, hint, nudge, nudge).
May 28 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Robert Fraser:

 However, the DMDFE's organization relies on being able to declare class 
 member functions separately from where they're defined, which is 
 impossible in D (hint, hint, nudge, nudge).


This current characteristics of D classes makes them a bit simpler to
read/understand/use.
Can you tell me (and/or show a small example) where you think such separation
may improve some D code?

Bye,
bearophile
May 28 2009
parent "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:gvmtt5$5os$1 digitalmars.com...

 Robert Fraser:

 However, the DMDFE's organization relies on being able to declare class
 member functions separately from where they're defined, which is
 impossible in D (hint, hint, nudge, nudge).


 This current characteristics of D classes makes them a bit simpler to 
 read/understand/use.
 Can you tell me (and/or show a small example) where you think such 
 separation may improve some D code?


Yea, I haven't seen anything yet about lifting the one-to-one module-to-file 
mapping that would make breaking bud/rebuild-like tools worthwhile. But I'd 
be interested in hearing any arguments in favor of doing so.
May 28 2009
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:gvml4m$2lg0$2 digitalmars.com...

 Kagamin wrote:

 I found recently that properly designed C++ code can live happily
 without all that esoteric macro/template crap and can be pretty
 readable and understandable even using nasty antipatterns. This being
 achieved simply by using C++ subset that is supported on various
 platforms. Code that does the job instead of casting black magic.


 The D compiler source doesn't use any templates, rtti, or clever macro 
 hacks. Whether it's well designed or not, I'll let others decide. It is 
 written in a "D-ish" style.


As someone who's (deliberately) barely touched C++ in about ten years, I 
found it surprisingly easy to find my way around. Although I did find it 
strange that there seemed to be a fair amount of duplicated code (at least 
WRT to error/warning reporting anyway).
May 28 2009
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
Kagamin wrote:

 
 I found recently that properly designed C++ code can live happily without all
that esoteric macro/template crap and can be pretty readable and understandable
even using nasty antipatterns. This being achieved simply by using C++ subset
that is supported on various platforms. Code that does the job instead of
casting black magic.


The problem is trying to get an entire team to code that way.
May 29 2009
prev sibling parent reply Tomas Lindquist Olsen <tomas.l.olsen gmail.com> writes:
On Wed, May 27, 2009 at 9:32 PM, Frits van Bommel
<fvbommel remwovexcapss.nl> wrote:

 Robert Clipsham wrote:

 Andrei Alexandrescu wrote:

 Great! Quick question - are you supporting or considering supporting D2?
 I looked on the project's home page and couldn't find that information.
 There's mention of druntime for D2 which makes me hopeful.

 Thanks,

 Andrei


 D2 support in LDC has been started, but it does not have any of D2's
 features implemented. I believe all that has been done is the frontend
 added. Last time I checked ldc + d2 would not compile.

 I believe that the plan is to make D1 solid (more so than DMD), before
 moving on to D2. One of the developers might be able to give a more accurate
 status.


 That's pretty accurate, actually.

 A while back somebody sent in a patch to get D2 support working, but by the
 time it got properly reviewed it was already outdated...

 The main problem on this front is that nobody currently working on LDC is
 particularly interested in D2.


The way the frontend is developed is also a factor.

Right now we have two frontend source dirs. One for D1 and one for D2.
Every time a new DMD release is out, this means: cleaning out the
files we don't need (or can't use) in LDC, merging the changes into
LDC, repeating for D2.

But merging isn't always trivial. Since we have quite a lot of changes
and conflicts are common.

Also often LDC bugreports are frontend related, and both D1 and D2
need identical fixes applied, this is often forgotten.

So, for now we're focusing on D1 and unfortunately D2 has fallen
behind to a point where it's just plain broken.

I would like to see more improvements to the way the DMD frontend is
developed - regarding other users than the DMD compiler - before
picking up D2 again. More specifically:

* Seperation of frontend and backend needs to be more clear. The file
structure is one thing, but it would be nice if the DMD backend
specific parts in the frontend code could be versioned out for DMD. A
simple ` #if IN_DMD ' would be a big improvement.

* put the code under version control, that could simplify pulling
fixes into our tree.

I was going to put a few more entries on this list, but I could
probably provide some patches there instead of just asking for things
to happen .. But the main point is, D1 support is more than enough
work already, however these two simple improvements would be a big
help, and will benefit others who wish to use the frontend in the
future as well.

-Tomas
May 27 2009
parent "Danny Wilson" <bluezenix gmail.com> writes:
Op Thu, 28 May 2009 03:08:45 +0200 schreef Tomas Lindquist Olsen  
<tomas.l.olsen gmail.com>:


 * put the code under version control, that could simplify pulling
 fixes into our tree.


You could setup a seperate branch with the DMD source, extract source  
tarball, commit.
Then merge the DMDFE branch into the LDC branches.

I dont know how to do this in hg, but i guess its very similar to git.

Or is it already done this way?
May 29 2009
prev sibling next sibling parent Robert Clipsham <robert octarineparrot.com> writes:
Christian Kamm wrote:

 The release 0.9.1 of LDC, the LLVM based compiler for the D programming 
 language, contains the following major improvements:
 
  * lots of bug fixes (http://www.dsource.org/projects/ldc/report/15)
  * x86-64 support is mature
  * inline asm improved (we now define D_Inline_Asm)
  * cross-compilation support
  * uses boehm-gc during compilation (x86-32 only)
  * D specific optimizations:
    * turn GC allocations to allocas if possible
    * simplify or remove certain calls to D runtime functions
 
 The command line interface of LDC now has added options in line with other 
 LLVM based tools. Please use the ldmd wrapper if you want a drop-in 
 replacement for DMD.
 
 Linux x86-32 download: 
 http://www.incasoftware.de/~kamm/ldc/ldc-0.9.1-x86_32.tar.bz2
 
 Linux x86-64 download: 
 http://www.incasoftware.de/~kamm/ldc/ldc-0.9.1-x86_64.tar.bz2
 
 Tomas Lindquist Olsen
 Christian Kamm
 Frits van Bommel
 Kelly Wilson


Congratulations on your hard work! This is a really big step for LDC and 
D, so thanks!
May 27 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Wed, May 27, 2009 at 2:19 PM, Christian Kamm
<kamm-incasoftware removethis.de> wrote:

 The release 0.9.1 of LDC, the LLVM based compiler for the D programming
 language, contains the following major improvements:

 =A0* lots of bug fixes (http://www.dsource.org/projects/ldc/report/15)
 =A0* x86-64 support is mature
 =A0* inline asm improved (we now define D_Inline_Asm)
 =A0* cross-compilation support
 =A0* uses boehm-gc during compilation (x86-32 only)
 =A0* D specific optimizations:
 =A0 * turn GC allocations to allocas if possible
 =A0 * simplify or remove certain calls to D runtime functions

 The command line interface of LDC now has added options in line with othe=


r

 LLVM based tools. Please use the ldmd wrapper if you want a drop-in
 replacement for DMD.

 Linux x86-32 download:
 http://www.incasoftware.de/~kamm/ldc/ldc-0.9.1-x86_32.tar.bz2

 Linux x86-64 download:
 http://www.incasoftware.de/~kamm/ldc/ldc-0.9.1-x86_64.tar.bz2


Rock on!
May 27 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Christian Kamm, el 27 de mayo a las 20:19 me escribiste:

 
 The release 0.9.1 of LDC, the LLVM based compiler for the D programming 
 language, contains the following major improvements:
 
  * lots of bug fixes (http://www.dsource.org/projects/ldc/report/15)
  * x86-64 support is mature
  * inline asm improved (we now define D_Inline_Asm)
  * cross-compilation support
  * uses boehm-gc during compilation (x86-32 only)
  * D specific optimizations:
    * turn GC allocations to allocas if possible
    * simplify or remove certain calls to D runtime functions
 
 The command line interface of LDC now has added options in line with other 
 LLVM based tools. Please use the ldmd wrapper if you want a drop-in 
 replacement for DMD.


Great, great news! Thanks for the hard work.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
May 27 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Christian Kamm:

 The release 0.9.1 of LDC, the LLVM based compiler for the D programming 
 language, contains the following major improvements:


Very good. I'll try this too.



    * turn GC allocations to allocas if possible


Phobos1 of DMD too has alloca, so can this optimization be folded in DMD too?



    * simplify or remove certain calls to D runtime functions


What calls?

Bye,
bearophile
May 27 2009
next sibling parent Robert Clipsham <robert octarineparrot.com> writes:
bearophile wrote:

    * turn GC allocations to allocas if possible


 Phobos1 of DMD too has alloca, so can this optimization be folded in DMD too?


I doubt it, these look like LLVM specific optimisations.


    * simplify or remove certain calls to D runtime functions


 What calls?


Looking at the source code (gen/passes/*.cpp):
  * _d_arraysetlengthT
  * _d_arraysetlengthiT
  * _d_array_cast_len
  * _d_array_slice_copy
  * _d_allocmemoryT
  * _d_newarrayT
  * _d_newarrayiT
  * _d_newarrayvT
  * _d_newarraymT
  * _d_newarraymiT
  * _d_newarraymvT
  * _d_allocclass

Are the runtime calls currently optimized. There may be more that I've 
missed, that looks like all of them though.
May 27 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
bearophile, el 27 de mayo a las 15:55 me escribiste:

 Christian Kamm:

 The release 0.9.1 of LDC, the LLVM based compiler for the D programming 
 language, contains the following major improvements:


 
 Very good. I'll try this too.
 
 

    * turn GC allocations to allocas if possible


 
 Phobos1 of DMD too has alloca, so can this optimization be folded in DMD too?


I don't think so, they are D specific LLVM optimization passes, see:
http://www.dsource.org/projects/ldc/browser/gen/passes


    * simplify or remove certain calls to D runtime functions


 
 What calls?


From what I saw in:
http://www.dsource.org/projects/ldc/browser/gen/passes/SimplifyDRuntimeCalls.cpp

- Remove libcall for arr.length = N if N <= arr.length
- Remove libcall for cast(T[]) arr if it's safe to do so.
- Remove libcall if the return value is unused.
- Turn slice copies into llvm.memcpy when safe


-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
May 27 2009
prev sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
bearophile wrote:

 Christian Kamm:

 The release 0.9.1 of LDC, the LLVM based compiler for the D programming 
 language, contains the following major improvements:


 
 Very good. I'll try this too.
 
 

    * turn GC allocations to allocas if possible


 
 Phobos1 of DMD too has alloca, so can this optimization be folded in DMD too?


These optimizations are done on LLVM IR, so unless DMD switches to LLVM they'll 
need to be completely reimplemented for DMD.

This one is only done for certain GC allocations by the way, not all of them. 
The ones currently implemented are:
  * new Struct/int/float/etc.,
  * uninitialized arrays (used for arr1 ~ arr2, for instance),
  * zero-initialized arrays (e.g. new int[N])
  * new Class, unless
    a) it has a destructor,
    b) it has a custom allocator (overloads new), or
    c) it has a custom deallocator (overloads delete).


    * simplify or remove certain calls to D runtime functions


 
 What calls?


Besides the GC calls turned into allocas, these are currently implemented:
  * For "arr.length = N", the runtime call is deleted if
    a) the resulting .ptr is unused,
    b) N == 0, or
    c) both arr.length and N are constant integers, and N <= arr.length.
       I'd like to extend this one to a more general N <= arr.length (i.e. not 
just constant integers), but I'm not quite sure what the best way to implement 
it is yet.

  * For "cast(T[]) some_array", the compiler generates a runtime call to
compute 
the new array length. This call will be optimized out if
    a) the old length was 0,
    b) T.sizeof == U.sizeof, where U is the element type of some_array, or
    c) T.sizeof % U.sizeof == 0

  * arr1[] = arr2[] is turned into a memcpy() if alias analysis can prove they 
don't overlap. (Only relevant if assertions or array bounds checks are enabled, 
as they both are by default, otherwise they're turned into memcpy() in the
first 
place)

  * Runtime calls that don't do anything but allocate GC memory (and optionally 
initialize it) are deleted if their return value is unused.
May 27 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Frits van Bommel:

Thank you for your answers.


 This one is only done for certain GC allocations by the way, not all of them. 
 The ones currently implemented are:
   * new Struct/int/float/etc.,
   * uninitialized arrays (used for arr1 ~ arr2, for instance),
   * zero-initialized arrays (e.g. new int[N])
   * new Class, unless
     a) it has a destructor,
     b) it has a custom allocator (overloads new), or
     c) it has a custom deallocator (overloads delete).


I'm trying to find situations where that's true, but in two small programs that
use both structs and classes (that don't escape the scope and follow your
unless list) I see:

call	_d_allocmemoryT
call _d_allocclass
Are those calls to variants of alloca()?

While looking for those alloca I have also tested code that has the following
two lines one after the other:
    auto a = new int[1000];
    a[] = 2;

That code is very common, because you currently can't write:
    auto a = new int[1000] = 2;

The latest LDC compiles that as:

	pushl	%esi
	subl	$4016, %esp
	leal	16(%esp), %esi
	movl	%esi, (%esp)
	movl	$4000, 8(%esp)
	movl	$0, 4(%esp)
	call	memset
	movl	%esi, (%esp)
	movl	$2, 8(%esp)
	movl	$1000, 4(%esp)
	call	_d_array_init_i32

I think the memset may be avoided.

Bye and thank you,
bearophile
May 27 2009
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
bearophile wrote:

 Frits van Bommel:
 
 Thank you for your answers.
 

 This one is only done for certain GC allocations by the way, not all of them. 
 The ones currently implemented are:
   * new Struct/int/float/etc.,
   * uninitialized arrays (used for arr1 ~ arr2, for instance),
   * zero-initialized arrays (e.g. new int[N])
   * new Class, unless
     a) it has a destructor,
     b) it has a custom allocator (overloads new), or
     c) it has a custom deallocator (overloads delete).


 
 I'm trying to find situations where that's true, but in two small programs
that use both structs and classes (that don't escape the scope and follow your
unless list) I see:
 
 call	_d_allocmemoryT
 call _d_allocclass
 Are those calls to variants of alloca()?


No, those are GC allocations.

This small program contains no gc allocations with ldc -O3:
-----
struct Struct {
     int i, j = 4;
}

class Class {
     int i, j = 6;
}

int frob(T)(T t) {
     t.i = 4;
     return t.j;
}

int withStruct() {
     return frob(new Struct);
}

int withClass() {
     return frob(new Class);
}
-----

It does still contain them when inlining is disabled, as it is by default with 
-O2 (aka -O); this seems to be because the LLVM pass that adds parameter 
attributes (like nocapture, better known as 'scope' in these newsgroups) is 
missing from the default list of optimizations :(. I'll fix this in the 
repository soon.

Another constraint I forgot to mention: it doesn't work for allocations in 
loops, because it's tricky to figure out whether the allocation is still 
reachable when the loop reaches the same position again.
(For this reason, the pass by default runs before each inliner run and once 
after all inlining is done since the inliner can inline code into loops, yet 
allows for simplifications that make escape analysis more accurate)


 While looking for those alloca I have also tested code that has the following
two lines one after the other:
     auto a = new int[1000];
     a[] = 2;
 
 That code is very common, because you currently can't write:
     auto a = new int[1000] = 2;
 
 The latest LDC compiles that as:
 
 	pushl	%esi
 	subl	$4016, %esp
 	leal	16(%esp), %esi
 	movl	%esi, (%esp)
 	movl	$4000, 8(%esp)
 	movl	$0, 4(%esp)
 	call	memset
 	movl	%esi, (%esp)
 	movl	$2, 8(%esp)
 	movl	$1000, 4(%esp)
 	call	_d_array_init_i32
 
 I think the memset may be avoided.


That's trickier to get right, because the optimizer would have to look ahead to 
see the new memset call is always followed by the initialization, with no reads 
in between.
The 1-byte element case can probably be handled by LLVM if _d_array_init_i8 is 
replaced by another memset, though. (and similarly, _d_array_init_i16 could be 
handled for cases like 0xFFFF, but not 0x1234, by turning it into memset).
May 27 2009
parent bearophile <bearophileHUGS lycos.com> writes:
Frits van Bommel:

Thanks for your answers (and your work).


 That's trickier to get right, because the optimizer would have to look ahead
to 
 see the new memset call is always followed by the initialization, with no
reads 
 in between.


I understand, and that may be more complex to do if the code is multi-thread.
It's not a very important optimization, because most times the initialization
time is a small percentage of the time spent to process the array. But it may
deserve to receive a look as a medium-low-priority optimization anyway.

Bye,
bearophile
May 27 2009
prev sibling next sibling parent reply Timo Gransch <timo.gransch web.de> writes:
First of all: Thanks for your your great work.

Unfortunately I still have the debugging problem already described in
the debugger group (using the x86-64 build on Ubuntu 9.04).

I compile a programm using

ldmd -g -debug test.d

Then I try to debug using gdb with the D patches:

(gdb) list
1	../sysdeps/x86_64/elf/start.S: No such file or directory.
	in ../sysdeps/x86_64/elf/start.S


Any hints on this?

Thanks and best regards,
Timo
May 27 2009
parent reply Christian Kamm <kamm-incasoftware removethis.de> writes:
Timo Gransch wrote:


 I compile a programm using
 
 ldmd -g -debug test.d
 
 Then I try to debug using gdb with the D patches:
 
 (gdb) list
 1	../sysdeps/x86_64/elf/start.S: No such file or directory.
 in ../sysdeps/x86_64/elf/start.S


On x86-32 that gives me a listing of the main function defined in the D 
runtime - but I am using a debug runtime. Does inserting a breakpoint in 
your code and running to that work?
May 28 2009
parent reply Timo Gransch <timo.gransch web.de> writes:
Christian Kamm schrieb:


 On x86-32 that gives me a listing of the main function defined in the D 
 runtime -


On Arch Linux/32 (using the official ldc binary), list prints the source
code of the compiled file, just the way it's supposed to.

(gdb) list
1	import tango.io.Console;
2	
3	int main(char[][] args)
4	{
5	    for (int i = 0; i < args.length; i++)
6	    {
7	        Cout(args[i] ~ "\n");
8	    }
9	
10	    return 0;


 but I am using a debug runtime. Does inserting a breakpoint in 
 your code and running to that work?


Back on x86-64 again:

(gdb) break main
Breakpoint 1 at 0x409150
(gdb) run
Starting program: /home/timo/tmp/testd/test
[Thread debugging using libthread_db enabled]
[New Thread 0x7fb54f2456f0 (LWP 7001)]
[Switching to Thread 0x7fb54f2456f0 (LWP 7001)]

Breakpoint 1, 0x0000000000409150 in main ()
Current language:  auto; currently asm
(gdb) step
Single stepping until exit from function main,
which has no line number information.
0x000000000040a830 in _STI_monitor_staticctor ()
(gdb) step
Single stepping until exit from function _STI_monitor_staticctor,
which has no line number information.
0x0000000000409183 in main ()


If I try to run list after that, the error message is different:

(gdb) list
1	/build/buildd/glibc-2.9/build-tree/amd64-libc/csu/crtn.S: No such file
or directory.
	in /build/buildd/glibc-2.9/build-tree/amd64-libc/csu/crtn.S

Thanks and best regards,
Timo
May 28 2009
parent reply Christian Kamm <kamm-incasoftware removethis.de> writes:
Timo Gransch wrote:

 Christian Kamm schrieb:

 but I am using a debug runtime. Does inserting a breakpoint in
 your code and running to that work?


 
 Back on x86-64 again:
 
 (gdb) break main
 Breakpoint 1 at 0x409150


Since there's main and _Dmain and I don't know how the GDB patches interact 
with breakpoint setting, can you try to make a breakpoint on the first line 
of your D main function (i.e. b myfile.d:15) and run to that?

I'm now also subscribed to D.debugger and saw your post there. Let's move 
the discussion.
May 29 2009
parent Timo Gransch <timo.gransch web.de> writes:
Christian Kamm schrieb:


 I'm now also subscribed to D.debugger and saw your post there. Let's move 
 the discussion.


I appended my answer to the existing thread 'Debugging LDC executables'.

Best regards,
Timo
May 30 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
While this code:

    typedef int Int2 = 2;
    auto a = cast(int[])(new Int2[1000]);
    
Produces:

	pushl	%esi
	subl	$8, %esp
	movl	$1000, 4(%esp)
	movl	$_D20TypeInfo_ATmain4Int26__initZ, (%esp)
	xorl	%esi, %esi
	call	_d_newarrayiT
	movl	%esi, %ecx
	
(I haven't taken the running time, so I don't know if this idiom is more
efficient with LDC).

Bye,
bearophile
May 27 2009
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
bearophile wrote:

 While this code:
 
     typedef int Int2 = 2;
     auto a = cast(int[])(new Int2[1000]);
     
 Produces:
 
 	pushl	%esi
 	subl	$8, %esp
 	movl	$1000, 4(%esp)
 	movl	$_D20TypeInfo_ATmain4Int26__initZ, (%esp)
 	xorl	%esi, %esi
 	call	_d_newarrayiT
 	movl	%esi, %ecx
 	
 (I haven't taken the running time, so I don't know if this idiom is more
efficient with LDC).


For arrays that escape, it's quite probably more efficient since it only gets 
initialized once this way.
For arrays that can get stack-promoted it may not be, because (non 
zero-)initialized arrays aren't eligible for that yet (as you can tell by the 
_d_newarray* call, which GC-allocates a new array and initializes it). So which 
is more efficient in that case depends on whether a GC allocation is more 
expensive than re-initializing 4 KB of data.
May 27 2009
prev sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Great news, happy to see x86_64 on the feature list :)
May 27 2009