You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After refactoring the build to integrate OptSched with the environment required by ROCm-4.5.2, OptSched no longer works nicely with LLVM machine scheduler registry.
To elaborate, when building LLVM, if we do not explicitly include our OptSched files in an AMDGPU source file (for example), the linker will optimize out all of the OptSched sources -- which results in the OptSched scheduler never being registered. The workaround is to directly include the registration code from within AMDGPU code (again, for example), in order to force include it.
At best, this is not very extensible, and, at worst, this will be the source of link time errors. Generally, GPU sources files have two pieces -- a piece that runs on CPU and a piece that runs on GPU. If we want to use OptSched to compile both the pieces of code (x86 and AMDGPU backends), we will need to force include both these schedule registrations. This may result in link time errors due to duplicate symbols. Resolving the link optimization will enable this use case.
Ah, this is probably the thing where the linker sees that it's unused so it skips it. I found this article: https://www.cppstories.com/2018/02/static-vars-static-lib/. Sounds like you can work around it by doing one of these things (or other options that I didn't think of):
In LLVM, either find some way to refer to these static variables, or call a registration function.
Use some sort of -Wl,--whole-archive flag, which tells the linker not to cut out unused parts of the static library. I have no experience with this.
Use an OBJECT library rather than a STATIC library. This is a CMake-only concept. An OBJECT library is just telling CMake about the bundle of files, so there's no static library generated; linking with it will just link the .o files together without archiving (IIUC).
The text was updated successfully, but these errors were encountered:
After refactoring the build to integrate OptSched with the environment required by ROCm-4.5.2, OptSched no longer works nicely with LLVM machine scheduler registry.
To elaborate, when building LLVM, if we do not explicitly include our OptSched files in an AMDGPU source file (for example), the linker will optimize out all of the OptSched sources -- which results in the OptSched scheduler never being registered. The workaround is to directly include the registration code from within AMDGPU code (again, for example), in order to force include it.
At best, this is not very extensible, and, at worst, this will be the source of link time errors. Generally, GPU sources files have two pieces -- a piece that runs on CPU and a piece that runs on GPU. If we want to use OptSched to compile both the pieces of code (x86 and AMDGPU backends), we will need to force include both these schedule registrations. This may result in link time errors due to duplicate symbols. Resolving the link optimization will enable this use case.
Originally posted by @Quincunx271 in #179 (comment)
Ah, this is probably the thing where the linker sees that it's unused so it skips it. I found this article: https://www.cppstories.com/2018/02/static-vars-static-lib/. Sounds like you can work around it by doing one of these things (or other options that I didn't think of):
-Wl,--whole-archive
flag, which tells the linker not to cut out unused parts of the static library. I have no experience with this.OBJECT
library rather than aSTATIC
library. This is a CMake-only concept. An OBJECT library is just telling CMake about the bundle of files, so there's no static library generated; linking with it will just link the.o
files together without archiving (IIUC).The text was updated successfully, but these errors were encountered: