In general, in the implementations I've seen, "link-time optimization" is a bit of a misnomer. It's more like a glorified version of `gcc -combine`. The "comp

In general, in the implementations I've seen, "link-time optimization" is a bit of a misnomer. It's more like a glorified version of `gcc -combine`. The "compiler" binary stuffs its half-finished results (IR) into fake object files, and the "linker" binary calls back into the compiler (built as a library) and sends it the IR from all the fake objects, which the compiler combines and builds into one giant, real object file. That object file is sent back to the linker, which goes on to do its normal job. (LLVM ThinLTO is a bit more advanced than that in terms of scalability and incrementality, but it maintains the same "hands-off" approach from the linker's perspective.) On the other hand, if the linker sees an object file passed to it is a real object, it doesn't send it to the compiler and handles it during the normal linking phase instead. And if you build a .s file, you always get a real object file, even if you passed -flto. TL;DR: It doesn't affect it.