This is an archive of the discontinued LLVM Phabricator instance.

[mlir][GPU] Add known_block_size and known_grid_size to gpu.func
ClosedPublic

Authored by krzysz00 on Dec 12 2022, 11:11 AM.

Details

Summary

In many cases, the the number of workgroups (the grid size) and the
number of workitems within each group (the block size) that a GPU
kernel will be launched with are known. For example, if gpu.launch is
called with constant block and grid sizes, we know that those are the
only possible sizes that will be used to launch that kernel. In other
cases, a custom code-generation pipeline that eventually produces GPU
kernels may know the launch dimensions of those kernels, or at least
may be able to provide an upper bound on them.

Other GPU programming systems, such as OpenCL, allow capturing such
information to enable compiler optimizations - see
reqd_work_group_size, but MLIR currently has no mechanism for doing so.

This set of attributes is the first step in enabling optimizations
based on the known launch dimensions of kernels. It extends the kernel
outline pass to set these bounds on kernels with constant launch
dimensions and extends integer range inference for GPU index
operations to account for the bounds when they are known.

Subsequent revisions will use this data when lowering GPU operations
to the ROCDL dialect.

Diff Detail

Event Timeline

krzysz00 created this revision.Dec 12 2022, 11:11 AM
krzysz00 requested review of this revision.Dec 12 2022, 11:11 AM
antiagainst added inline comments.Dec 21 2022, 10:38 AM
mlir/lib/Dialect/GPU/IR/InferIntRangeInterfaceImpls.cpp
134

Shouldn't this be getKnownLaunchDim(*this, LaunchDims::Block) * getKnownLaunchDim(*this, LaunchDims::Grid) - 1 if both are available?

mlir/lib/Dialect/GPU/Transforms/KernelOutlining.cpp
153

Nit: name it as inferConstantDimsAttr or something similar?

antiagainst requested changes to this revision.Dec 21 2022, 10:38 AM
This revision now requires changes to proceed.Dec 21 2022, 10:38 AM
krzysz00 updated this revision to Diff 484693.Dec 21 2022, 3:10 PM

Address review comments

krzysz00 marked an inline comment as done.Dec 21 2022, 3:10 PM
krzysz00 added inline comments.
mlir/lib/Dialect/GPU/IR/InferIntRangeInterfaceImpls.cpp
134

%res = gpu.global_id [dim] is, as far as I'm aware, exactly

%tid = gpu.thread_id [dim]
%bid = gpu.block_id[dim]
%res = arith.muli %tid, %bid : index

which means the upper bound is the upper bound on thread_id (known block dimension - 1) times the upper bound on he grid dimension (known grid dimension - 1).

krzysz00 marked an inline comment as not done.Dec 21 2022, 8:56 PM
krzysz00 added inline comments.
mlir/lib/Dialect/GPU/IR/InferIntRangeInterfaceImpls.cpp
134

Wait, no, you're right, good catch. I'll fix it soon

krzysz00 updated this revision to Diff 484926.Dec 22 2022, 12:20 PM
krzysz00 marked an inline comment as not done.

Address bug caught in review, remove .transform()

antiagainst accepted this revision.Dec 22 2022, 12:29 PM
This revision is now accepted and ready to land.Dec 22 2022, 12:29 PM

The valueByDim() switch in InferIntRangeInterfaceImpls.cpp appears to have broken the Windows buildbot (https://lab.llvm.org/buildbot/#/builders/13/builds/30180/steps/6/logs/stdio).

C:\buildbot\mlir-x64-windows-ninja\llvm-project\mlir\lib\Dialect\GPU\IR\InferIntRangeInterfaceImpls.cpp(49) : error C2220: the following warning is treated as an error
C:\buildbot\mlir-x64-windows-ninja\llvm-project\mlir\lib\Dialect\GPU\IR\InferIntRangeInterfaceImpls.cpp(49) : warning C4715: 'valueByDim': not all control paths return a value

@NathanialMcVicar Can you add a return nullptr; to the end of the function? Or a llvm_unreachable() go make the error clearer? (Not at a computer right now so I can't do it, but I can take care of it in a few hours if it still needs fixing)

Looks like this broke the windows mlir buildbot: https://lab.llvm.org/buildbot/#/builders/13/builds/30140

If you can fix it today, can we revert it so we don't go into the weekend with a red bot?

Go ahead and revert, I'll land the fox after the holiday, probably on Monday or Tuesday