Ship with LTO default libs on Linux & macOS #2640

kinke · 2018-03-31T15:00:28Z

This allows additional bitcode libs to be generated simultaneously with the normal druntime/Phobos libs (i.e., single compilation) by including something like -DBUILD_LTO_LIBS=ON -DD_FLAGS="-w;-flto=thin" in the CMake command line (additional D_FLAGS entry here to include the ThinLTO module summaries in the bitcode files; not needed for FullLTO).

This then allows linking against the LTO default libs via ldc2 -flto=<thin|full> ... -defaultlib=phobos2-ldc-lto,druntime-ldc-lto; unfortunately, I couldn't test this yet, as my LLVM 6 Linux build has a 0-byte LLVMgold.so...

kinke · 2018-03-31T17:05:20Z

Tested it now; it's principally working, but the C and asm parts of druntime/Phobos are missing in the bitcode libs. We don't have these object files explicitly, CMake takes care of compiling them, so that's blocking this LTO-libs-for-free scheme.

kinke · 2018-03-31T19:14:04Z

Working now. A Phobos-hello-world can be linked against the normal libs as well as with both thin & full LTO against the ThinLTO bitcode libs (incl. C/ASM parts in machine code):

void main()
{
    import std.stdio;
    writefln("Hello world, %d bits", cast(int) size_t.sizeof * 8);
}

bin/ldc2 -O -release ../hello.d -of=hello_normal -linker=gold
  => 833 KB, 1.6 secs
bin/ldc2 -O -release ../hello.d -of=hello_full -flto=full -defaultlib=phobos2-ldc-bc,druntime-ldc-bc -linker=gold
  => 691 KB, 6.9 secs
bin/ldc2 -O -release ../hello.d -of=hello_thin -flto=thin -defaultlib=phobos2-ldc-bc,druntime-ldc-bc -linker=gold
  => 690 KB, 6.2 secs

kinke · 2018-03-31T22:44:04Z

I'd prefer an -lto suffix instead of -bc (and BUILD_LTO_LIBS over BUILD_BC_LIBS); I don't think there's much room for backwards compatibility concerns (considering that BUILD_BC_LIBS=ON was broken for default BUILD_SHARED_LIBS=BOTH etc.).

JohanEngelen · 2018-04-02T14:43:45Z

.circleci/config.yml

@@ -258,7 +270,7 @@ jobs:
      - LLVM_VERSION: 5.0.1
      - HOST_LDC_VERSION: 1.6.0
      - BOOTSTRAP_CMAKE_FLAGS: "-DCMAKE_CXX_FLAGS='-stdlib=libc++' -DCMAKE_EXE_LINKER_FLAGS=-lc++"
-      - EXTRA_CMAKE_FLAGS: "-DMULTILIB=ON -DCMAKE_CXX_FLAGS='-stdlib=libc++' -DCMAKE_EXE_LINKER_FLAGS=-lc++"
+      - EXTRA_CMAKE_FLAGS: "-DMULTILIB=ON -DBUILD_BC_LIBS=ON -DD_FLAGS='-w;-flto=thin' -DCMAKE_CXX_FLAGS='-stdlib=libc++' -DCMAKE_EXE_LINKER_FLAGS=-lc++"


Adding -flto to D_FLAGS also builds the normal libs with that option, right? But then how do the tests pass: how does linking succeed without specifying the LLVMgold plugin on the linker line for normal tests without LTO ?

Adding -flto to D_FLAGS also builds the normal libs with that option, right?

In combination with BUILD_BC_LIBS=ON, this yields a command line ldc2 -c -output-o -output-bc -flto=thin ...; producing both the normal object file in machine code and the LTO bitcode file (-flto=thin only affecting the module summaries in the bitcode files in this case). After this PR's first commit that is.

how does linking succeed without specifying the LLVMgold plugin

We use LDC to firstly compile the modules, one object (and bitcode file for BUILD_BC_LIBS) per druntime/Phobos module (and D_FLAGS only affect compilation). We then archive them to static libs via separate LDC invokations - normal libs containing machine code only, and bitcode/LTO libs containing bitcode for the D parts and machine code for the C/ASM parts. The shared libs are obviously only generated for the normal machine-code objects.

So specifying -flto=... for linking is only required when choosing the bitcode/LTO libs explicitly via -defaultlib=..., which is only tested by the CircleCI integration test so far (Linux only; linker crashing on OSX for both thin and full LTO tests).

This scheme allows the user to choose LTO for his code only via -flto=... and LTO incl. default libs via -flto=... -defaultlib=....

producing both the normal object file in machine code and the LTO bitcode file

OK got it.

JohanEngelen · 2018-04-02T14:43:58Z

This is pretty neat.

I'd prefer an -lto suffix instead of -bc (and BUILD_LTO_LIBS over BUILD_BC_LIBS)

Me too.

kinke · 2018-04-11T22:21:20Z

@JohanEngelen: Do you have any clues as to why both trivial LTO tests fail on Circle OSX (Assertion failed: (WasErased && "Expected to drop a reference"))? Do we not default to using the shipped-with LTO plugin on OSX?

kinke · 2018-04-14T12:03:29Z

Btw the CircleCI package sizes are increased by about 10%.

JohanEngelen · 2018-04-14T13:18:39Z

I've seen the "Expected to drop a reference" failure before, I think when trying to create LTO version of ldc release package. Back then, I couldn't figure out what the bug is.
On OSX we explicitly pass the LDC LTO plugin to the linker.

Need to find time to look at it closely again...

…-flto=...`

…libs

Feasible by using LDC for archiving (via 'D' linker language), opening up the door for including C/ASM parts by source file (and another compilation of the few of them), as used for the normal druntime/Phobos libs. As LDC doesn't support .bc files as pure archiving/linking input directly (they are injected into the first compiled module/object, but if there is none, they are ignored), the .bc files need to be renamed to .bc.o files before creating the static libs. While at it, get rid of redundancies by extending set_common_library_properties().

LTO with debug libs probably isn't very useful.

kinke · 2018-04-16T21:24:33Z

Oh wow, the CircleCI macOS LTO integration tests now work with LLVM 6. :)

JohanEngelen · 2018-04-18T09:35:14Z

Oh wow, the CircleCI macOS LTO integration tests now work with LLVM 6. :)

There was an XCode update recently, perhaps related?

kinke · 2018-04-18T10:38:50Z

I don't think so, we're using the XCode 9.0 CircleCI image.

kinke force-pushed the ltolibs branch 2 times, most recently from ce67728 to 7036593 Compare March 31, 2018 22:33

kinke changed the title ~~Prepare for shipping with LTO default libs~~ Ship with LTO default libs on Linux & macOS Mar 31, 2018

kinke force-pushed the ltolibs branch from 7036593 to 52cda05 Compare March 31, 2018 23:30

JohanEngelen reviewed Apr 2, 2018

View reviewed changes

kinke force-pushed the ltolibs branch from 5e19a76 to 2ebf5e2 Compare April 15, 2018 00:07

kinke added 6 commits April 16, 2018 22:13

Emit both object file and LTO bitcode file via `-output-o -output-bc …

2faf469

…-flto=...`

CMake: Only emit bitcode libs per set of static non-unittest runtime …

b1e2ddf

…libs

CMake: Install release versions of bitcode default libs

9eeb2dd

LTO with debug libs probably isn't very useful.

CircleCI: Include LTO/bitcode default libs

405deee

CMake: Rename BUILD_BC_LIBS to BUILD_LTO_LIBS and -bc lib suffix to -lto

801370c

kinke force-pushed the ltolibs branch from 2ebf5e2 to 6443992 Compare April 16, 2018 20:15

Re-enable LTO tests for CircleCI OSX now with LLVM 6

d28743d

kinke force-pushed the ltolibs branch from 6443992 to d28743d Compare April 16, 2018 21:29

kinke merged commit d5871a1 into ldc-developers:master Apr 17, 2018

kinke deleted the ltolibs branch April 17, 2018 01:09

jondegenhardt mentioned this pull request Dec 22, 2020

Bulding tsv-utils with LTO and PGO on Archlinux eBay/tsv-utils#325

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Ship with LTO default libs on Linux & macOS #2640

Ship with LTO default libs on Linux & macOS #2640

kinke commented Mar 31, 2018 •

edited

Loading

kinke commented Mar 31, 2018

kinke commented Mar 31, 2018

kinke commented Mar 31, 2018 •

edited

Loading

JohanEngelen Apr 2, 2018

kinke Apr 2, 2018 •

edited

Loading

kinke Apr 2, 2018

JohanEngelen Apr 2, 2018

JohanEngelen commented Apr 2, 2018

kinke commented Apr 11, 2018 •

edited

Loading

kinke commented Apr 14, 2018

JohanEngelen commented Apr 14, 2018

kinke commented Apr 16, 2018

JohanEngelen commented Apr 18, 2018

kinke commented Apr 18, 2018

Ship with LTO default libs on Linux & macOS #2640

Ship with LTO default libs on Linux & macOS #2640

Conversation

kinke commented Mar 31, 2018 • edited Loading

kinke commented Mar 31, 2018

kinke commented Mar 31, 2018

kinke commented Mar 31, 2018 • edited Loading

JohanEngelen Apr 2, 2018

Choose a reason for hiding this comment

kinke Apr 2, 2018 • edited Loading

Choose a reason for hiding this comment

kinke Apr 2, 2018

Choose a reason for hiding this comment

JohanEngelen Apr 2, 2018

Choose a reason for hiding this comment

JohanEngelen commented Apr 2, 2018

kinke commented Apr 11, 2018 • edited Loading

kinke commented Apr 14, 2018

JohanEngelen commented Apr 14, 2018

kinke commented Apr 16, 2018

JohanEngelen commented Apr 18, 2018

kinke commented Apr 18, 2018

kinke commented Mar 31, 2018 •

edited

Loading

kinke commented Mar 31, 2018 •

edited

Loading

kinke Apr 2, 2018 •

edited

Loading

kinke commented Apr 11, 2018 •

edited

Loading