Remove JIT+LTO fragment database#1927
Merged
rapids-bot[bot] merged 4 commits intorapidsai:mainfrom Mar 17, 2026
Merged
Conversation
Rather than register each fragment in a runtime class with a string key, "register" them with the linker using template specialization. This solves a number of problems: 1. It simplifies the code by removing the `FragmentDatabase` class. 2. It addresses rapidsai#1909 (comment) by bypassing the issue entirely. There is no longer a need to build the fragment name string at runtime. 3. For clients that use the `cuvs_static` static library, it allows the linker to pick and choose which fragment symbols it needs rather than including all of them with every client just in case any of them are needed. 4. Since there is no longer a need for `$<WHOLE_ARCHIVE:...>` linkage, there is no need for the `cuvs_jit_lto_kernels` target at all, thus simplifying the CMake code too.
KyleFromNVIDIA
added
improvement
Contributor
robertmaynard
left a comment
robertmaynard
left a comment
There was a problem hiding this comment.
Does this interact with user defined kernels/functions? Do we lose any support for that in the future?
Member
Author
|
We might have to rework it a bit, but it should still be supported. The UDF library takes the user-provided code, compiles it into a fragment, and calls |
divyegala
reviewed
Mar 17, 2026
divyegala
approved these changes
Mar 17, 2026
KyleFromNVIDIA
added
breaking
Member
Author
|
/merge |
lowener
pushed a commit
to lowener/cuvs
that referenced
this pull request
Mar 30, 2026
Rather than register each fragment in a runtime class with a string key, "register" them with the linker using template specialization. This solves a number of problems: 1. It simplifies the code by removing the `FragmentDatabase` class. 2. It addresses rapidsai#1909 (comment) by bypassing the issue entirely. There is no longer a need to build the fragment name string at runtime. 3. For clients that use the `cuvs_static` static library, it allows the linker to pick and choose which fragment symbols it needs rather than including all of them with every client just in case any of them are needed. 4. Since there is no longer a need for `$<WHOLE_ARCHIVE:...>` linkage, there is no need for the `cuvs_jit_lto_kernels` target at all, thus simplifying the CMake code too. Authors: - Kyle Edwards (https://github.com/KyleFromNVIDIA) Approvers: - Divye Gala (https://github.com/divyegala) URL: rapidsai#1927
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Rather than register each fragment in a runtime class with a string key, "register" them with the linker using template specialization. This solves a number of problems:
FragmentDatabaseclass.cuvs_staticstatic library, it allows the linker to pick and choose which fragment symbols it needs rather than including all of them with every client just in case any of them are needed.$<WHOLE_ARCHIVE:...>linkage, there is no need for thecuvs_jit_lto_kernelstarget at all, thus simplifying the CMake code too.