www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - pragma(inline, true) / llvmAttr("alwaysinline") cross module inlining

reply Marcel <marcelpi97 gmail.com> writes:
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?
May 06
parent reply kinke <noone nowhere.com> writes:
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.
May 06
parent reply kinke <noone nowhere.com> writes:
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.]
May 06
parent reply Marcel <marcelpi97 gmail.com> writes:
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?
May 07
parent reply kinke <noone nowhere.com> writes:
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?
May 07
parent reply Marcel <marcelpi97 gmail.com> writes:
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.
May 07
next sibling parent Marcel <marcelpi97 gmail.com> writes:
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).
May 07
prev sibling parent reply kinke <noone nowhere.com> writes:
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.
May 07
parent reply Marcel <marcelpi97 gmail.com> writes:
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.
May 07
next sibling parent kinke <noone nowhere.com> writes:
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).
May 07
prev sibling parent reply kinke <noone nowhere.com> writes:
On Thursday, 7 May 2020 at 22:14:16 UTC, Marcel wrote:
 Fixed. Unfortunately the issue of the corrupt .lib still 
 persists.
I've just tried another potential source of error, which occurs when generating (not linking) the static LTO library. That requires generating the static lib with LDC (`-lib`), as it uses LLVM's librarian/archiver with bitcode support. When using MS lib.exe, I get that LNK1107 error you've mentioned (with an object file prefix in the error msg though, unlike your example). So VisualD might use the MS librarian unconditionally in your case...
May 07
parent reply Marcel <marcelpi97 gmail.com> writes:
On Thursday, 7 May 2020 at 23:05:30 UTC, kinke wrote:
 On Thursday, 7 May 2020 at 22:14:16 UTC, Marcel wrote:
 Fixed. Unfortunately the issue of the corrupt .lib still 
 persists.
I've just tried another potential source of error, which occurs when generating (not linking) the static LTO library. That requires generating the static lib with LDC (`-lib`), as it uses LLVM's librarian/archiver with bitcode support. When using MS lib.exe, I get that LNK1107 error you've mentioned (with an object file prefix in the error msg though, unlike your example). So VisualD might use the MS librarian unconditionally in your case...
That's a shame, I'll try using dub later.
May 07
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 08/05/2020 01:28, Marcel wrote:
 On Thursday, 7 May 2020 at 23:05:30 UTC, kinke wrote:
 On Thursday, 7 May 2020 at 22:14:16 UTC, Marcel wrote:
 Fixed. Unfortunately the issue of the corrupt .lib still persists.
I've just tried another potential source of error, which occurs when generating (not linking) the static LTO library. That requires generating the static lib with LDC (`-lib`), as it uses LLVM's librarian/archiver with bitcode support. When using MS lib.exe, I get that LNK1107 error you've mentioned (with an object file prefix in the error msg though, unlike your example). So VisualD might use the MS librarian unconditionally in your case...
That's a shame, I'll try using dub later.
Please file a bug report at issues.dlang.org for compoonent visuald.
May 08
parent Marcel <marcelpi97 gmail.com> writes:
On Friday, 8 May 2020 at 07:04:28 UTC, Rainer Schuetze wrote:
 On 08/05/2020 01:28, Marcel wrote:
 On Thursday, 7 May 2020 at 23:05:30 UTC, kinke wrote:
 On Thursday, 7 May 2020 at 22:14:16 UTC, Marcel wrote:
 [...]
I've just tried another potential source of error, which occurs when generating (not linking) the static LTO library. That requires generating the static lib with LDC (`-lib`), as it uses LLVM's librarian/archiver with bitcode support. When using MS lib.exe, I get that LNK1107 error you've mentioned (with an object file prefix in the error msg though, unlike your example). So VisualD might use the MS librarian unconditionally in your case...
That's a shame, I'll try using dub later.
Please file a bug report at issues.dlang.org for compoonent visuald.
Done :)
May 08