yxsamliu wrote:
@zmodem a question on how you'd like the `/MT` vs `/MD` issue handled long-term.
The regression comes from `InstrProfilingPlatformROCm.cpp` depending on the
sanitizer interception library. There are two distinct uses of that library in
the file:
1. Symbol loading (both Linux and Windows): `DynamicLoaderAvailable()`,
`OpenLibrary("amdhip64.dll" / "libamdhip64.so")`, `LookupSymbol(...)` to find
the HIP API at runtime. This is the static-link collection path.
2. Module-load interception (Linux only, `#if defined(__linux__)`):
`INTERCEPT_FUNCTION(hipModuleLoad…)` for the dynamic `hipModuleLoad*` path,
compiled out on Windows.
This PR takes the minimal approach: default `COMPILER_RT_BUILD_PROFILE_ROCM`
off on Windows, which keeps the profile archive on `/MT` there. That works
because Windows device PGO isn't wired up end-to-end yet, but it does disable
the Windows path rather than fix the dependency.
The alternative, if you'd rather the profile library not depend on
`RTInterception` / `sanitizer_common` at all, is to decouple symbol loading
from the interception library: replace the `__interception::` helpers in use #1
with direct `dlopen`/`dlsym` (Linux) and `LoadLibrary`/`GetProcAddress`
(Windows). The heavyweight machinery (`INTERCEPT_FUNCTION`, trampolines,
`sanitizer_common`) would then only be pulled in for the Linux-only path #2.
That keeps the archive `/MT` on Windows and keeps Windows static-link
collection working, and it also drops the `sanitizer_common` `pthread_*`
coupling that hit the ppc64le buildbot. This matches @jhuber6's earlier
suggestion to write a small internal layer for the HIP case.
My plan is to land this minimal version to get the tree green and do the
decouple as a follow-up if you prefer removing the dependency over defaulting
it off. Which would you like?
https://github.com/llvm/llvm-project/pull/201499
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
