Can you describe better the rationale for why this is necessary? Building two separate output files, .lto.o with bitcode, and a separate .o with native objects, and depending on the correct one from the correct target doesn’t seem super-tricky, and seems generally preferable.
IMO, the Unified LTO format should be considered a hard prerequisite for this, and always enabled for this mode.
I think the correct path forward now is to deprecate and remove all of the existing command-line options and related infrastructure which currently deals with non-LTO embedded bitcode.
I say that because:
- The current options and sections were originally intended for – and only really worked properly for – embedded bitcode for non-LTO re-compilation of the original object files (e.g. Apple’s AppStore, where Apple can rebuilds existing IR with a modified backend configuration).
- Apple is, to my knowledge, the only entity that has actually used this.
- Apple announced that embedded bitcode is no longer supported by their appstore infrastructure, and nobody should be uploading embedded bitcode anymore.
Once we’ve dropped all the existing stuff, we can consider and introduce new section names and new options for doing LTO-targeted fat bitcode, without any of the current baggage.