[FEA]: Make Linker.backend a classmethod #714

Activity

1. github-project-automation

   added this to CCCLon Jun 17, 2025
2. github-project-automation

   moved this to Todo in CCCLon Jun 17, 2025
3. github-actions

   added

   triageNeeds the team's attentionNeeds the team's attention

   on Jun 17, 2025
4. leofang

   added this to the cuda.core beta 5 milestone on Jun 18, 2025
5. leofang

   added

   P0High priority - Must do!High priority - Must do!

   cuda.coreEverything related to the cuda.core moduleEverything related to the cuda.core module

   enhancementAny code-related improvementsAny code-related improvements

   and removed

   triageNeeds the team's attentionNeeds the team's attention

   on Jun 18, 2025
6. leofang

   self-assigned this

   on Jun 18, 2025
7. kkraus14 commented on Jun 18, 2025

   

   kkraus14

   on Jun 18, 2025

   Collaborator

   More actions

   Exposing Linker.backend forces the user to understand the support matrix and versioning matrix of things like nvjitlink and the driver cuLink APIs. Instead, I wonder if we can add a classmethod where the user provides info like:

   • Is LTOIR being used? If so, which version of the CTK was used to generate it if known?
   • Is PTX being used? If so, which version of the PTX ISA?

   Based on this, we could do the following:

   • If a user gives us only LTOIR without a version, we give them a "yes" as long as we have nvjitlink available to us (we always should)
   • If a user gives us only LTOIR with a version, we give them a "yes" as long as we have a new enough nvjitlink version available to us
     • User could be running in an older environment with an older nvjitlink version than what the user used to generate the LTOIR in which case we'd return a "no"
   • If a user gives us only PTX without a version, we give them a "yes"
     • We could probably parse the ISA version from the actual ptx file / buffer easily enough to make a smarter decision and follow the path as if someone passed an ISA version
   • If a user gives us only PTX with an ISA version, we give them a "yes" as long as we have a sufficiently new version of either nvjitlink or the driver available to us. Otherwise, we give a "no".
   • If a user gives us both LTOIR and PTX, we give them a "yes" as long as we have a sufficiently new version of nvjitlink available to us
     • If the LTOIR version is newer than the nvjitlink version, we give a "no"
     • If the PTX ISA version is newer than the nvjitlink version, we give a "no"
       • We could maybe handle this situation where if the driver is new enough we use the cuLink* APIs to lower the PTX down to SASS and then link that SASS using nvjitlink?
8. leofang

   modified the milestones: cuda.core beta 5, cuda.core parking lot on Jun 27, 2025
9. leofang

   removed their assignment

   on Jan 20, 2026
10. rparolin

    added

    cuda.coreEverything related to the cuda.core moduleEverything related to the cuda.core module

    and removed

    cuda.coreEverything related to the cuda.core moduleEverything related to the cuda.core module

    on Apr 2, 2026
11. rparolin

    removed this from the cuda.core backlog milestone on Apr 2, 2026
12. github-project-automation

    moved this from Todo to In Progress in CCCLon Apr 14, 2026
13. leofang

    closed this as completedon May 7, 2026