HIP currently uses -mlink-builtin-bitcode to link all bitcode libraries, which
changes the linkage of functions to be internal once they are linked in. This
works for common bitcode libraries since these functions are not intended
to be exposed for external callers.
However, the functions in the sanitizer bitcode library is intended to be
called by instructions generated by the sanitizer pass. If their linkage is
changed to internal, their parameters may be altered by optimizations before
the sanitizer pass, which renders them unusable by the sanitizer pass.
To fix this issue, HIP toolchain links the sanitizer bitcode library with
-mlink-bitcode-file, which does not change the linkage.
A struct BitCodeLibraryInfo is introduced in ToolChain as a generic
approach to pass the bitcode library information between ToolChain and Tool.
It appears that what we dealing with here is an on/off switch for whether we want to internalize symbols.
Perhaps it should be implemented as such.
getHIPDeviceLibs() will set the bool flag indicating *what* we want to do with the library and then the toolchain-specific code will decide *how* to make it happen. Currently it translates into specific linking option, but it may be something else. getHIPDeviceLibs does not need to know that.
The code will remain essentially the same, it's mostly the naming exercise.