LDC 0.12.0 beta 1 released, please help test!

[David Nadlinger]

On Tue, Oct 15, 2013 at 11:16 PM, bearophile <bearophileHUGS at 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 at 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