[FEA]: Make `Linker.backend` a `classmethod`

[brandon-b-miller]

Is this a duplicate?

• I confirmed there appear to be no duplicate issues for this request and that I agree to the Code of Conduct

Area

cuda.core

Is your feature request related to a problem? Please describe.

Linker fully abstracts the linking details away from the user, but in certain cases the user might need to query the backend. For example, a user linking static code might prefer to pass ltoir rather than ptx if they know nvjitlink is available. Linker.backend exposes this property but requires instantiating a Linker instance to query. We should make it possible to get the info without doing so.

Describe the solution you'd like

I'd like Linker.backend to return driver or nvjitlink without instantiating the class

Describe alternatives you've considered

Instantiating a LinkerOptions in a function that catches the warning

Additional context

NVIDIA/numba-cuda#133

[kkraus14]

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?