================
@@ -8010,15 +8010,19 @@ void Clang::ConstructJob(Compilation &C, const
JobAction &JA,
}
}
- if (Args.hasArg(options::OPT_forder_file_instrumentation)) {
- CmdArgs.push_back("-forder-file-instrumentation");
- // Enable order file instrumentation when ThinLTO is not on. When ThinLTO
is
- // on, we need to pass these flags as linker flags and that will be
handled
- // outside of the compiler.
- if (!IsUsingLTO) {
- CmdArgs.push_back("-mllvm");
- CmdArgs.push_back("-enable-order-file-instrumentation");
- }
+ if (const Arg *A =
+ Args.getLastArg(options::OPT_forder_file_instrumentation)) {
+ D.Diag(diag::warn_drv_deprecated_arg)
+ << A->getAsString(Args) << /*hasReplacement=*/true
+ << "-mllvm -pgo-temporal-instrumentation";
----------------
llvm-beanz wrote:
`-forder-file-instrumentation` was not only used by Meta. At a minimum I’ve
been using it, and my former team at Apple was too. The instrumentation-based
approaches to order file generation are significantly more robust than the
dtrace-based solution
(https://github.com/llvm/llvm-project/blob/main/clang/utils/perf-training/perf-helper.py#L128),
that I upstreamed from Apple’s internal tooling in 2016
(https://github.com/llvm/llvm-project/commit/d8b5bde5d6300f15b6f798eed73b712378261314).
I don’t know if Apple ever updated their Clang builds to use the
instrumentation-based approach, but it is vastly superior. Notably dtrace is
not deterministic, so using it to drive part of a build process is not ideal.
I worry about having a deprecation policy allowing deprecating a publicly
documented option for a non-public option. If the new feature isn’t stable, and
the old feature still works, why are we deprecating it?
https://github.com/llvm/llvm-project/pull/121514
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
