yxsamliu wrote: Thanks, both suggestions make sense and I'll take them.
On the split: I'll break this into a runtime PR and a compiler PR. The runtime part (the compiler-rt profile library changes) is self-contained and can land first; the compiler part (the LLVM instrumentation and Clang codegen that emit calls into the runtime) depends on the runtime ABI but builds independently, so it can follow. That keeps each PR smaller and lets the disruptive part land on its own. On the separate library: I like it, and I think it's the cleanest of the options. I'll add an opt-in `clang_rt.profile_rocm` that carries the ROCm support (the collection runtime plus the interceptor dependency) and is built the way that target needs (e.g. /MD on Windows), and leave the existing `clang_rt.profile` unchanged so current users are not affected. The driver will link the ROCm library on the host side only when building HIP with `-fprofile-generate`. I'll close this PR and open the runtime PR in that shape. Thanks for the review. https://github.com/llvm/llvm-project/pull/201499 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
