This is an archive of the discontinued LLVM Phabricator instance.

MLIR/Cuda: Add the appropriate "HINTS" on CMake find_library and mark these REQUIRED
ClosedPublic

Authored by mehdi_amini on May 29 2023, 1:40 AM.

Details

Summary

The cmake logic to find cuda paths exposes some paths to search for the cuda
library, we need to propagate this through the call for find_library.
This was already done for cuSparse but not for cuda.

Diff Detail

Event Timeline

mehdi_amini created this revision.May 29 2023, 1:40 AM
mehdi_amini requested review of this revision.May 29 2023, 1:40 AM
stellaraccident accepted this revision.EditedMay 29 2023, 9:03 AM

This seems ok to me, but it caused me to look at the layering of the libraries and this CMake file, and it seems unfortunate to.

I wish the dialect and transforms CMake files were in the IR and Transforms directories vs being loose leaf at the top.

Also, it seems like there should be two libraries for transforms instead of monkey patching the one with optional features (Transforms, SerializationTransforms). That was, it would be clear from the targets what is depended on vs just getting link errors if the extra CMake flag were not set.

Neither blocking this patch -- just noting that this directory could use some cleanup.

This revision is now accepted and ready to land.May 29 2023, 9:03 AM

I landed this because that'll unblock reviving the mlir-nvidia bot right now :)

We should follow up, I'd like to understand a bit more what you have in mind and how the ExecutionEngine can get these optional features in a less intrusive way maybe.

Sure, can follow up. Generally, I think that distinct dependencies should imply distinct library targets vs having the definition of the library changed based on an optional feature flag. That way, CMake will complain if depending on something not enabled (versus just falling through to an undefined symbol that needs to be untangled for why it isn't present).