[clang] [lld] [llvm] [LTO] enable `ObjCARCContractPass` only on optimized build (PR #101114)

[Nuri Amari via cfe-commits]

NuriAmari wrote:

This pass is added in numerous places: https://github.com/search?q=repo%3Allvm%2Fllvm-project%20createObjCARCContractPass&type=code, and we were hoping to consolidate all the places and instead schedule it by default, or behind some kind of predicate. We haven’t been able to find a predicate that satisfies all the use cases, there always seems to be a case where the required analysis passes are scheduled when not necessarily always required.

In practice, I think this pass is already scheduled by default, or for optimized builds in almost all configurations. Auditing the places it’s added, the legacy LTO backend adds it unconditionally: https://github.com/llvm/llvm-project/blob/8364a6e108faea1a6f05f7bb53720a6fc101fed2/llvm/lib/LTO/ThinLTOCodeGenerator.cpp#L340
https://github.com/llvm/llvm-project/blob/f70f1228035c9610de38e0e376afdacb647c4ad9/llvm/lib/LTO/LTOCodeGenerator.cpp#L140 LLD for MachO injects it into the new LTO backend via a hook: https://github.com/llvm/llvm-project/blob/f70f1228035c9610de38e0e376afdacb647c4ad9/lld/MachO/LTO.cpp#L52 Clang adds it for non-LTO compiles here: https://github.com/llvm/llvm-project/blob/f70f1228035c9610de38e0e376afdacb647c4ad9/clang/lib/CodeGen/BackendUtil.cpp#L595

Granted that leaves LTO builds that are using the new LTO backend (except LLD for MachO), and distributed thin-LTO builds which currently don’t schedule it. Ultimately, our goal here is to schedule the pass for distributed thin-LTO compiles as the new test demonstrates.

We could go back to a change like: https://github.com/llvm/llvm-project/pull/92331/commits/66ddf609c0e77867ec48c17136fb80d1e482041d

That would schedule the pass unconditionally for distributed thin-LTO compiles, on top of those configurations it already runs for. The analysis passes would still be run in some cases that are not required, but I don’t see how to avoid that. If we prefer that change, over the current, we could go that direction instead.

https://github.com/llvm/llvm-project/pull/101114