Support precompiled LTO-IR in librtcx - #22704
Conversation
- fragments.cmake: add_fragment(), add_composite_fragment(), get_jit_fragment_architectures() - compute_matrix_product.cmake/.py: Cartesian product of JSON matrices - embed.cmake: add OUTPUT_DIRECTORY parameter - rtcx.hpp: lto_kernel, get_lto_linked_kernel, AlgorithmPlanner, AlgorithmLauncher - rtcx.cpp: implementation of link-launch API
nvJitLink 12.9 successfully compiles, links, and executes LTO fatbins for sm_70. The guard was speculative — tested empirically on V100 (sm_70) and confirmed working. Arch deprecation is handled by get_jit_fragment_architectures dropping old archs from default lists in future toolkit versions.
vyasr
added
feature request
github-actions
Bot
added
libcudf
|
|
||
| } // namespace | ||
|
|
||
| lto_kernel get_lto_linked_kernel(cache_t& cache, |
There was a problem hiding this comment.
Having reviewed #22654 I think I agree with the approach there and get_lto_linked_kernel should be part of cudf proper and not librtcx. All the compiler flags etc should be handled by each library using librtcx. Presumably we can merge this function with the get_kernel function in #22654 once that PR merges.
| * @param cache Cache used for linked libraries | ||
| * @return Type-safe launcher for the linked kernel | ||
| */ | ||
| [[nodiscard]] AlgorithmLauncher get_launcher(cache_t& cache) const |
There was a problem hiding this comment.
Rather than accepting a cache directly we might want to accept a callable wrapping the cache + get_lto_linked_kernel so that more of the logic is deferred to the calling library (libcudf) instead of being embedded inside rtcx's own functions.
|
At this point I feel comfortable closing this PR in favor of #22680. We'll probably pull some parts of this PR into a new one just for adding murmurhash support once librtcx + LTO-IR is fully working in libcudf. |
1 participant
Description
This PR aims to rebuild the support for managing matrices of LTO-IR fragments from #22390 on top of the infrastructure introduced by #21625. It steals some of the earlier concepts present in #21625 (some of which are also now present in #22680). This PR makes some different choices for what is scoped within librtcx and what is part of cudf compared to #22654, and that's something we should discuss.
Checklist