[GSoC2020] LTO support for swift

[compnerd (Saleem Abdulrasool)]

@denis631

After watching video about thinLTO I have a better picture on how stuff works in clang, but I still have trouble understanding what exactly should ^that mean, or better said what exactly has to be implemented.

The exact things that need to be implemented are roughly:

Phase 1

• swift driver changes for providing flags for LTO
• swift driver changes to invoke the clang linker driver properly for enabling LTO
• swift frontend changes to emit LLVM BC instead of object files

Measurements for this phase would be interesting as they would identify the benefits of extra IPO of the IRGen (generic, non-language specific optimizations)

Phase 2

• changes to LLD to add support setting multiple compiler pipelines for LTO
• changes to swift frontend to support multiple pipelines
• changes to swift frontend to emit SIB instead of IRGen
• changes to LLD to setup a swift pipeline if a SIB is encountered, call back into swift to SILGen
• changes to the pipeline to do IPO with language specific considerations - e.g. late monomorphisation of generics, late devirt of calls

Measurements of this phase would be interesting as they identify the benefits of IPO of SILGen (language specific optimizations).

The latter should actually be interesting as doing LTO on SIL should even allow us to consider dropping VWTs.

@denis631

But according to the interface of BticodeCompiler in LTO.h there are only two methods, add bitcode file and compile, no callbacks, or anything.

Its the implementation of those that are interesting. The invocation of the "bitcode compiler" is the callback.

@denis631

Or this is exactly what you meant with extending it in order to support other compilers. If yes, then how should this look like and should these callbacks be called?

Yes, extending that to support swift would be an extension, and what I was referring to. They would look like setting up a swift pipeline and executing it.

@denis631

What is meant by Swift LTO? I was assuming that it works with LLVM IR data which is input language agnostic, it could be C++ or Rust, or anything else.

Yes, there are things you can do with language agnostic optimizations, but doing this at the SIL level is also interesting with the ability to internalize functions and VWTs.

@denis631

Does this imply adding a custom LinkAction or "passing a flag" to an existing LinkAction ?

Yes, the LinkAction would need to grow some fields in order to support the new behaviors.