Erase all address spaces and get inlined ukernels (#19646)

The `LLVMGPUCastAddressSpaceFunction` pass was selectively erasing the
shared memory address space from pointers around Call ops to achieve
inlining. This PR generalizes that to erasing all address spaces after
checking with its original author that there wasn't anything intentional
here:
[discord](https://discord.com/channels/689900678990135345/1282818085153407038/1326577591557296272)

This has the intended effect of allowing AMDGPU ukernels to get inlined
into their callers.

There is a side benefit of not having to duplicate ukernels for the
various combinations of address spaces of their pointer parameters. This
benefit will be partly rolled back if and when we do assembly ukernels,
as these will need to know the address spaces to write different
instructions, but at least for C ukernels it is nice.

It was counter-intuitive to me that erasing address spaces was possible
at all. The key is that these ukernels only get compiled to LLVM IR, not
to ISA, and the resulting IR gets inlined into a caller where the
addrspacecast was done and where the actual address space is known.
After inlining, the compiler is still able to propagate the actual
address spaces all the way into the inlined ukernel code.

For the current `multi_mma` ukernel there was no immediate problem. The
changes to it in this PR are reaping the benefits of inlining: now the
`unroll_*` parameters become compile-time constants after inlining so we
get to simply declare our accumulator tile as a VLA and let it get
specialized to a normal fixed-size array. No need anymore to use an
arbitrary fixed size array and try to guard that with assertions.

For the exising `argmax` ukernels, the inlining revealed a preexisting
issue: these ukernels are reductions to a single scalar and instead of
returning it by value, write their result value to an output buffer
(which happens to be LDS memory, but the address space doesn't matter).
The problem was that there was no synchronization between the thread
writing the value in the ukernel, and the threads reading the value in
the caller. Solved by adding a `__threadfence_block()`, which compiles
to almost nothing in ISA (s_waitcnt, which we have anyway around memory
accesses) but prevents IR rewrites removing the loads from the output
buffer.

I added `__threadfence_block()` to common.h, copied from AMD device
library headers, along with a few other synchronization functions which
we anticipate will be useful in other ukernels. `__syncthreads` is not
used in this PR.

Signed-off-by: Benoit Jacob <jacob.benoit.1@gmail.com>
7 files changed
tree: 7b8472561ea7caf29bfa7d46b937d632dcb9f779
  1. .github/
  2. build_tools/
  3. compiler/
  4. docs/
  5. experimental/
  6. integrations/
  7. lib/
  8. llvm-external-projects/
  9. runtime/
  10. samples/
  11. tests/
  12. third_party/
  13. tools/
  14. .bazel_to_cmake.cfg.py
  15. .bazelignore
  16. .bazelrc
  17. .bazelversion
  18. .clang-format
  19. .git-blame-ignore-revs
  20. .gitattributes
  21. .gitignore
  22. .gitmodules
  23. .pre-commit-config.yaml
  24. .yamllint.yml
  25. AUTHORS
  26. BUILD.bazel
  27. CITATION.cff
  28. CMakeLists.txt
  29. configure_bazel.py
  30. CONTRIBUTING.md
  31. LICENSE
  32. MAINTAINERS.md
  33. README.md
  34. RELEASING.md
  35. WORKSPACE
README.md

IREE: Intermediate Representation Execution Environment

IREE (Intermediate Representation Execution Environment, pronounced as “eerie”) is an MLIR-based end-to-end compiler and runtime that lowers Machine Learning (ML) models to a unified IR that scales up to meet the needs of the datacenter and down to satisfy the constraints and special considerations of mobile and edge deployments.

See our website for project details, user guides, and instructions on building from source.

IREE Discord Status pre-commit OpenSSF Best Practices

Project news

Project status

Release status

Releases notes are published on GitHub releases.

PackageRelease status
GitHub release (stable)GitHub Release
GitHub release (nightly)GitHub Release
Python iree-base-compilerPyPI version
Python iree-base-runtimePyPI version

Build status

CI PkgCI

Nightly build status

Operating systemBuild status
LinuxCI - Linux arm64 clang
macOSCI - macOS x64 clang
WindowsCI - Windows x64 MSVC

For the full list of workflows see https://iree.dev/developers/general/github-actions/.

Communication channels

Related project channels

  • MLIR topic within LLVM Discourse: IREE is enabled by and heavily relies on MLIR. IREE sometimes is referred to in certain MLIR discussions. Useful if you are also interested in MLIR evolution.

Architecture overview

IREE Architecture IREE Architecture

See our website for more information.

Presentations and talks

Community meeting recordings: IREE YouTube channel

DateTitleRecordingSlides
2021-06-09IREE Runtime Design Tech Talkrecordingslides
2020-08-20IREE CodeGen (MLIR Open Design Meeting)recordingslides
2020-03-18Interactive HAL IR Walkthroughrecording
2020-01-31End-to-end MLIR Workflow in IREE (MLIR Open Design Meeting)recordingslides

License

IREE is licensed under the terms of the Apache 2.0 License with LLVM Exceptions. See LICENSE for more information.