Hello!
I have a simple wrapper type around LLVM's atomic intrinsics in a static library, which I use in a separate, also static, library. Today I noticed that even though all of the type's methods are explicitly marked as forceinline, that their body consists of a single instruction and that I'm using "-enable-cross-module-inlining=true", all method calls are NOT inlined.
This happens regardless of whether I'm using llvmAttr("alwaysinline"), pragma(inline, true) or even if I remove all inlining annotations.
Am I missing something or is this a compiler bug? Does anyone know of any workaround?

On Wednesday, 6 May 2020 at 20:16:19 UTC, Marcel wrote:
> Hello!
> I have a simple wrapper type around LLVM's atomic intrinsics in a static library, which I use in a separate, also static, library. Today I noticed that even though all of the type's methods are explicitly marked as forceinline, that their body consists of a single instruction and that I'm using "-enable-cross-module-inlining=true", all method calls are NOT inlined.
> This happens regardless of whether I'm using llvmAttr("alwaysinline"), pragma(inline, true) or even if I remove all inlining annotations.
> Am I missing something or is this a compiler bug? Does anyone know of any workaround?

This is a known bug of -enable-cross-module-inlining when compiling several object files in a single cmdline (the default when building a static library) - a function can only be emitted into a single object file.

The workaround is using LTO.

On Thursday, 7 May 2020 at 01:51:22 UTC, kinke wrote:
> The workaround is using LTO.

Or building each object file separately. [With parallelization, this might be faster than all-at-once compilation.]

On Thursday, 7 May 2020 at 01:56:42 UTC, kinke wrote:
> On Thursday, 7 May 2020 at 01:51:22 UTC, kinke wrote:
>> The workaround is using LTO.
>
> Or building each object file separately. [With parallelization, this might be faster than all-at-once compilation.]

Thank you :)
I have another problem though, when using -flto (full or thin) I get weird error messages when linking the library with the final executable:

C:\foo\bin\release\x64\foo.lib : fatal error LNK1107: invalid or corrupt file: cannot read at 0x1C4C8

The command line parameters I'm using:

-mattr=sse,sse2
-preview=intpromote
-inline-threshold=256
-inlinehint-threshold=512
-enable-cross-module-inlining=true
-flto=full
-linker=gold
-nogc

What am I missing?

On Thursday, 7 May 2020 at 09:57:24 UTC, Marcel wrote:
> I have another problem though, when using -flto (full or thin) I get weird error messages when linking the library with the final executable

Make sure to use -flto when linking too, not just when compiling the lib(s). LDC defaults to the bundled lld-link.exe on Windows then, which does support LTO libs.

> -mattr=sse,sse2

Implicit for x86_64 targets.

> -enable-cross-module-inlining=true

Doesn't make much sense with LTO.

> -linker=gold

On Windows?

On Thursday, 7 May 2020 at 13:45:14 UTC, kinke wrote:
> On Thursday, 7 May 2020 at 09:57:24 UTC, Marcel wrote:
>> I have another problem though, when using -flto (full or thin) I get weird error messages when linking the library with the final executable
>
> Make sure to use -flto when linking too, not just when compiling the lib(s). LDC defaults to the bundled lld-link.exe on Windows then, which does support LTO libs.
>
>> -mattr=sse,sse2
>
> Implicit for x86_64 targets.
>
>> -enable-cross-module-inlining=true
>
> Doesn't make much sense with LTO.
>
>> -linker=gold
>
> On Windows?

I'm using VisualD on Windows 10. It seems that enabling LTO makes the linker lld-link (forget about -linker=gold) complain about /noopttls.

Oh, if I add -flto to the executable lld-link complains about noopttls and if I remove it I get LNK1107 (invalid or corrupt file).

On Thursday, 7 May 2020 at 17:21:13 UTC, Marcel wrote:
> I'm using VisualD on Windows 10. It seems that enabling LTO makes the linker lld-link (forget about -linker=gold) complain about /noopttls.

(Undocumented) /noopttls is then added by VisualD, as it's an old workaround for druntime < 2.076 + VS 2017+ and not needed anymore.

On Thursday, 7 May 2020 at 17:40:29 UTC, kinke wrote:
> On Thursday, 7 May 2020 at 17:21:13 UTC, Marcel wrote:
>> I'm using VisualD on Windows 10. It seems that enabling LTO makes the linker lld-link (forget about -linker=gold) complain about /noopttls.
>
> (Undocumented) /noopttls is then added by VisualD, as it's an old workaround for druntime < 2.076 + VS 2017+ and not needed anymore.

Fixed. Unfortunately the issue of the corrupt .lib still persists.

On Thursday, 7 May 2020 at 22:14:16 UTC, Marcel wrote:
> Fixed. Unfortunately the issue of the corrupt .lib still persists.

Have you tried to link in the shell directly, without VisualD? If you get that LNK error, that's from the MS linker, which of course doesn't have the faintest idea about LLVM bitcode. So lld-link.exe is required (and as said, the default linker in such a scenario unless another build tool interferes).

Note that the ldc2 binaries in the official LDC packages are built with LTO (across C++ and D, incl. druntime from D host compiler), so it's not like LTO would be completely untested and totally unbuggy, as the reports here in the forum might suggest (as always, the majority for which it's working is silent).