| Issue |
71345
|
| Summary |
How to use distributed thin lto?
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
zcfh
|
I got a **3%** optimization effect by using `thinlto`, which I think is great. But it will increase my link time from **10 seconds to 20 minutes** when using lld, so **I hope to find some means to speed up thinlto.** At present, I learned from the official website [documents](https://blog.llvm.org/2016/06/thinlto-scalable-and-incremental-lto.html) that you can use `--thinlto-index-only` to generate indexes and optimize each bitcode (.o) separately, and **use distributed construction to speed up the process.**
The problem I’m having is that by following the command below, I’m linking only the .o and everything works fine. **There are some usage issues when linking with .a**
**compiler and generate index**
```shell
clang++ lib.cc -flto=thin -O3 -c -o lib.o
clang++ main.cc -flto=thin -O3 -c -o main.o
clang++ main.o lib.o -fuse-ld=lld -o main -Wl,--thinlto-index-_only_=main.rsp,--thinlto-emit-imports-files
clang++ -O3 -o lib.thinlto.o -x ir lib.o -c -fthinlto-index=lib.o.thinlto.bc
clang++ -O3 -o main.thinlto.o -x ir main.o -c -fthinlto-index=main.o.thinlto.bc
clang++ lib.thinlto.o main.thinlto.o -o -fuse-ld=lld -o main
```
But when I package `lib.o` into `lib.a`, the generated files are a little different.
```
clang++ main.o lib.a -fuse-ld=lld -o main -Wl,--thinlto-index-_only_=main.rsp,--thinlto-emit-imports-files
```
This generates `lib.a(lib.o at 94).imports` and `lib.a(lib.o at 94).thinlto.bc`.
I understand this may be the offset of lib.o in lib.a, and I want to run.
```
clang++ -O3 -o lib.thinlto.o -x ir lib.o -c -fthinlto-index="lib.a( lib.o at 94).thinlto.bc"
```
get `Error loading imported file lib.a(lib.o at 94)`.
I tried renaming lib.o to "lib.a(lib.o at 94)" and it worked
```
mv lib.o "lib.a(lib.o at 94)"
clang++ -O3 -o lib.thinlto.o -x ir "lib.a(lib.o at 94)" -c -fthinlto -index="lib.a(lib.o at 94).thinlto.bc"
```
This seems to work fine, but integrating it into a distributed build system seems unlikely.
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs