This is an archive of the discontinued LLVM Phabricator instance.

[mlir][sparse][gpu] first implementation of the GPU libgen approach
ClosedPublic

Authored by aartbik on May 8 2023, 7:38 PM.

Details

Summary

The sparse compiler now has two prototype strategies for GPU acceleration:

  • CUDA codegen: this converts sparsified code to CUDA threads
  • CUDA libgen: this converts pre-sparsified code to cuSPARSE library calls

This revision introduces the first steps required for the second approach.

Diff Detail

Event Timeline

aartbik created this revision.May 8 2023, 7:38 PM
Herald added a project: Restricted Project. · View Herald Transcript
aartbik requested review of this revision.May 8 2023, 7:38 PM
Matt added a subscriber: Matt.May 8 2023, 10:59 PM
aartbik updated this revision to Diff 520767.May 9 2023, 11:33 AM

rebased with main

aartbik updated this revision to Diff 520769.May 9 2023, 11:34 AM

minor edit

aartbik updated this revision to Diff 521113.May 10 2023, 2:59 PM

rebased with main

looks good to me, few minor comments/questions. I see a few places where the comments are CUDA specific, do you think this is something that will stay specific to cuda or does it make sense to try to make it more API agnostic?

mlir/lib/Dialect/SparseTensor/Transforms/SparseGPUCodegen.cpp
303–305

is this comment up to date? It does look like you are generating GPU dialect ops?

366

nit: spell out type when it is not explicit from the definition

637

is this redundant with the checks of the maps?

668

replace "CUDA threads" by "GPU threads"?

utils/bazel/llvm-project-overlay/mlir/BUILD.bazel
7760 ↗(On Diff #521113)

not sure why this shows up in this patch? This seems unrelated to the rest of the changes?

aartbik marked 5 inline comments as done.May 12 2023, 1:54 PM
aartbik added inline comments.
mlir/lib/Dialect/SparseTensor/Transforms/SparseGPUCodegen.cpp
303–305

Good catch! This was left-over from a very old patch I had with library calls ;-)

637

I could reorder a bit, but, as written, the test protects the iteratorType access
it is probably also a tiny bit faster for non-matching patterns...

utils/bazel/llvm-project-overlay/mlir/BUILD.bazel
7760 ↗(On Diff #521113)

Yeah, that is because my tool to prep the revision takes all bazel related changes in the workspace.
It goes away now that I rebased with main (and the parent revision has been submitted)

aartbik updated this revision to Diff 521787.May 12 2023, 1:56 PM
aartbik marked 3 inline comments as done.

rebased with main, addressed comments

aartbik updated this revision to Diff 521789.May 12 2023, 2:02 PM

spell out auto for non-explicit case

aartbik updated this revision to Diff 521794.May 12 2023, 2:15 PM

use more generic GPU nomenclature

aartbik updated this revision to Diff 521795.May 12 2023, 2:19 PM

minor edit

ThomasRaoux accepted this revision.May 12 2023, 2:43 PM

Looks great!

mlir/lib/Dialect/SparseTensor/Transforms/SparseGPUCodegen.cpp
398

nit: I believe the type should be spelled out here and below as well.

This revision is now accepted and ready to land.May 12 2023, 2:43 PM

looks like you need to clang-format as well

Peiming added inline comments.May 12 2023, 3:23 PM
mlir/lib/Dialect/SparseTensor/Transforms/SparseGPUCodegen.cpp
308

Maybe llvm::PatternMatch will make your life easier here?

aartbik updated this revision to Diff 521820.May 12 2023, 3:26 PM
aartbik marked an inline comment as done.

lint and review comments

aartbik updated this revision to Diff 521821.May 12 2023, 3:29 PM

auto -> type

aartbik marked an inline comment as done.May 12 2023, 4:45 PM
aartbik added inline comments.
mlir/lib/Dialect/SparseTensor/Transforms/SparseGPUCodegen.cpp
308

I will look into that for next revisions (where we expect more patterns) just to avoid breaking the currently working code ;-)

This revision was automatically updated to reflect the committed changes.
aartbik marked an inline comment as done.