Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Work better with LLVM's scheduler registry #180

Open
jrbyrnes opened this issue May 26, 2022 · 0 comments
Open

Work better with LLVM's scheduler registry #180

jrbyrnes opened this issue May 26, 2022 · 0 comments

Comments

@jrbyrnes
Copy link
Contributor

jrbyrnes commented May 26, 2022

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):

  • 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).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant