Thread overview
LDC 1.15.0-beta1
Mar 09
kinke
Mar 09
Dennis
Mar 12
kinke
Mar 10
Manu
Mar 10
kinke
March 09
Glad to announce the first beta for LDC 1.15:

* Based on D 2.085.0.
* Support for LLVM 8.0. The prebuilt packages ship with LLVM 8.0.0-rc4 and include the Khronos SPIRV-LLVM-Translator, so that dcompute can now emit OpenCL too.
* New -lowmem switch to enable the GC for the front-end, trading compile times for less required memory (in some cases, by more than 60%).
* Dropped support for 32-bit macOS. Min macOS version for prebuilt package raised to 10.9.
* Fix: functions annotated with `pragma(inline, true)` are implicitly cross-module-inlined again.

Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.15.0-beta1

Please help test, and thanks to all contributors!
March 09
Thanks!

On Saturday, 9 March 2019 at 19:57:36 UTC, kinke wrote:
> * Based on D 2.085.0.

Yes, gimme those assertion failure messages! I hope the fix for using it with attributes (https://github.com/dlang/druntime/pull/2479) gets merged in time for the stable release of LDC 1.15.

> * New -lowmem switch to enable the GC for the front-end, trading compile times for less required memory (in some cases, by more than 60%).

Cool, interesting that dmd doesn't appear to have this yet but LDC does already.
March 09
On Sat, Mar 9, 2019 at 12:00 PM kinke via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>
> Glad to announce the first beta for LDC 1.15:
>
> * Based on D 2.085.0.
> * Support for LLVM 8.0. The prebuilt packages ship with LLVM
> 8.0.0-rc4 and include the Khronos SPIRV-LLVM-Translator, so that
> dcompute can now emit OpenCL too.
> * New -lowmem switch to enable the GC for the front-end, trading
> compile times for less required memory (in some cases, by more
> than 60%).
> * Dropped support for 32-bit macOS. Min macOS version for
> prebuilt package raised to 10.9.
> * Fix: functions annotated with `pragma(inline, true)` are
> implicitly cross-module-inlined again.
>
> Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.15.0-beta1
>
> Please help test, and thanks to all contributors!

Can you explain what this means:

* Fix: functions annotated with `pragma(inline, true)` are
implicitly cross-module-inlined again.

??
March 10
On Sunday, 10 March 2019 at 02:05:37 UTC, Manu wrote:
> Can you explain what this means:
>
> * Fix: functions annotated with `pragma(inline, true)` are
> implicitly cross-module-inlined again.

`pragma(inline, true)` functions have only been inlined in the same compilation unit since LDC v1.1 (without explicit `-enable-cross-module-inlining`). Now they are inlined across compilation units again, as before v1.1 (and independent from the -O level). E.g., this means that you don't need LTO to get rid of calls to std.math trampolines for LLVM intrinsics such as:

pragma(inline, true)
real fabs(real x) @safe pure nothrow @nogc { return llvm_fabs(x); }
March 10
On 3/10/19 7:41 AM, kinke wrote:
> On Sunday, 10 March 2019 at 02:05:37 UTC, Manu wrote:
>> Can you explain what this means:
>>
>> * Fix: functions annotated with `pragma(inline, true)` are
>> implicitly cross-module-inlined again.
> 
> `pragma(inline, true)` functions have only been inlined in the same compilation unit since LDC v1.1 (without explicit `-enable-cross-module-inlining`). Now they are inlined across compilation units again, as before v1.1 (and independent from the -O level). E.g., this means that you don't need LTO to get rid of calls to std.math trampolines for LLVM intrinsics such as:
> 
> pragma(inline, true)
> real fabs(real x) @safe pure nothrow @nogc { return llvm_fabs(x); }

THANK YOU!
I did not know about this regression.

I get about a 4.5% speed increase on my limited dataset with ldc-1.15-beta1 compared to ldc-1.14. Hopefully will be more on larger dataset (smaller set overwhelmed by startup costs).
March 11
On Sunday, 10 March 2019 at 11:41:36 UTC, kinke wrote:
> On Sunday, 10 March 2019 at 02:05:37 UTC, Manu wrote:
>> Can you explain what this means:
>>
>> * Fix: functions annotated with `pragma(inline, true)` are
>> implicitly cross-module-inlined again.
>
> `pragma(inline, true)` functions have only been inlined in the same compilation unit since LDC v1.1 (without explicit `-enable-cross-module-inlining`). Now they are inlined across compilation units again, as before v1.1 (and independent from the -O level). E.g., this means that you don't need LTO to get rid of calls to std.math trampolines for LLVM intrinsics such as:
>
> pragma(inline, true)
> real fabs(real x) @safe pure nothrow @nogc { return llvm_fabs(x); }

Thank you! For a while we've been forced to use `dub --combined` to have inlining (don't know why) but it used to work indeed. Very nice that we can build separately again.
March 12
On Saturday, 9 March 2019 at 19:57:36 UTC, kinke wrote:
> Please help test, and thanks to all contributors!

Thank you very much guys!

I opened an issue https://github.com/ldc-developers/ldc/issues/3023 about exports in WebAssembly.

ldc 1.14's default is to export pretty much everything, and ldc 1.15-beta1's default is to export only the bare minimum.

Of course I want something in between :) See the issue for more information.
March 12
On Saturday, 9 March 2019 at 22:08:27 UTC, Dennis wrote:
> Yes, gimme those assertion failure messages! I hope the fix for using it with attributes (https://github.com/dlang/druntime/pull/2479) gets merged in time for the stable release of LDC 1.15.

https://github.com/dlang/druntime/pull/2479 was just merged!

Can we please merge this into LDC 1.15?!
March 12
On Tuesday, 12 March 2019 at 12:09:11 UTC, Per Nordlöw wrote:
> https://github.com/dlang/druntime/pull/2479 was just merged!
>
> Can we please merge this into LDC 1.15?!

As usual, v1.15.0 final will be based on the first DMD point release (2.085.1), so just make sure your fixes end up in DMD's stable branches before the tag, as done in this case.
March 13
On Tuesday, 12 March 2019 at 20:15:30 UTC, kinke wrote:
> As usual, v1.15.0 final will be based on the first DMD point release (2.085.1), so just make sure your fixes end up in DMD's stable branches before the tag, as done in this case.

Wonderful!