> Please, could you check if this patch https://gist.github.com/redstar/5800e9dc85a1d5626e7e fixes the problem?

Yes I already tested the DigitalMarsWin64 version successfully in the meantime.

On Tuesday, 24 June 2014 at 10:35:06 UTC, Kai Nacke wrote:
> Hi bearophile!
>
> On Tuesday, 24 June 2014 at 08:42:50 UTC, bearophile wrote:
>> Kai Nacke:
>>
>>> The first release of LDC 0.13.0 is here!
>>
>> I'll try this version soon. I'd like switches to increase the inlining threshold and to use unsafe floating point optimizations (similar to -ffast-math of GCC).
>>
>> Bye,
>> bearophile
>
> I'll try to implement some new functionality soon. (I have a long list of things I like to do - this is one of them.)
>
> Regards,
> Kai

I'd love to see -ffast-math in ldc.

Some timings on a 1st gen corei7 for floating-point heavy code (doubles):

gdc -frelease -fno-bounds-check -O3 -march=native
    27171ms

gdc -frelease -fno-bounds-check -Ofast -march=native
    16786ms

ldc2 -release -O5 -disable-boundscheck -mcpu=native
    35523ms

ldc2 -release -O5 -disable-boundscheck
    34864ms

ldc2 -release -O2 -disable-boundscheck
    34724ms

ldc2 -release -O1 -disable-boundscheck
    42365ms

ldmd2 -release -inline -noboundscheck -O
    31982ms


P.S. there's an overhead of about 4000ms in there from allocating memory and calls to fftw.

On 1 Jul 2014, at 15:29, John Colvin via digitalmars-d-ldc wrote:
> I'd love to see -ffast-math in ldc.

This shouldn't be hard to add at all. We need a few new command line switches (like [1], but probably using FlagParser like [2] for uniformity), and adapt our TargetMachine creation code [3] to respect them (like in [4]).

Would be great if you could cook up a pull request or otherwise open an issue on the tracker.

I'd suggest going for the LLVM-style names like in [1], as the GCC semantics of -ffast-math and friends are a bit strange.

Best,
David


[1] https://github.com/llvm-mirror/llvm/blob/36019bbc3ad87a66e3555e09fc579781a84a96f9/include/llvm/CodeGen/CommandFlags.h#L90-L119
[2] https://github.com/ldc-developers/ldc/blob/69442a2dd85d147eadc68b53a7a1c346dbf579f3/driver/cl_options.cpp#L346
[3] https://github.com/ldc-developers/ldc/blob/69442a2dd85d147eadc68b53a7a1c346dbf579f3/driver/targetmachine.cpp#L417
[4] https://github.com/llvm-mirror/llvm/blob/36019bbc3ad87a66e3555e09fc579781a84a96f9/include/llvm/CodeGen/CommandFlags.h#L226-L231

On 1 Jul 2014, at 15:29, John Colvin via digitalmars-d-ldc wrote:
> ldmd2 -release -inline -noboundscheck -O
>  31982ms

Oh, and you can use the -singleobj option with the ldc2 driver to get the same (good) timings as with ldmd. It enables cross-module optimizations like inlining and arguably should be the default for ldc2 too.

Cheers,
David

On Sunday, 6 July 2014 at 23:40:01 UTC, David Nadlinger via digitalmars-d-ldc wrote:
> On 1 Jul 2014, at 15:29, John Colvin via digitalmars-d-ldc wrote:
>> ldmd2 -release -inline -noboundscheck -O
>> 31982ms
>
> Oh, and you can use the -singleobj option with the ldc2 driver to get the same (good) timings as with ldmd. It enables cross-module optimizations like inlining and arguably should be the default for ldc2 too.
>
> Cheers,
> David

It should definitely be the default for optimised builds. What are the disadvantages?

On 8 Jul 2014, at 1:40, John Colvin via digitalmars-d-ldc wrote:
> It should definitely be the default for optimised builds. What are the disadvantages?

I agree.

The downside to making -singleobj the default is mainly breaking backwards compatibility at this point, as it – nomen est omen – causes LDC to only emit a single object file, which might affect some build systems.

As to why it hasn't been the default in the first place, I am not sure (Christian, do you remember any details?). The decision might have been made with flexibility in terms of incremental compilation in mind, which would maybe depend on having one object file per module. However, it has since been established that Walter is not interested in making the frontend support reusing an object file as part of a compilation with different parameters (e.g. first run ldc2 -c foo.d bar.d baz.d, and later run only ldc2 -c foo.d if foo has changed, cf. issue 3274 and others). Thus, emitting only one object file wouldn't break "correct" incremental compilation setups either.

Cheers,
David

Hmm now with git master I get
import\core\stdc\stdio.d(644): error : Function type does not match previously declared function with the same mangled name: _get_osfhandle

Cause std.process has to redefine _get_osfhandle -.-