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.
Its the implementation of those that are interesting. The invocation of the "bitcode compiler" is the callback.
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.
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.
Yes, the LinkAction
would need to grow some fields in order to support the new behaviors.