Skip to content

Work better with LLVM's scheduler registry #180

@jrbyrnes

Description

@jrbyrnes

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions