| commit | e99179861c9e2af4796f51e09de271c885e88836 | [log] [tgz] |
|---|---|---|
| author | Benoit Jacob <jacob.benoit.1@gmail.com> | Thu Feb 29 23:11:52 2024 -0500 |
| committer | GitHub <noreply@github.com> | Thu Feb 29 23:11:52 2024 -0500 |
| tree | e87a6294dca490426f21cba5b13a2b7f8ad5aa27 | |
| parent | 96a09d967bf169ee7a787f8cf6eb74f3d12e0a8c [diff] |
Unroll fixed-trip-count loops within mmt4d ukernel tile functions. (#16626) mmt4d ukernels rely on fixed-trip-count for loops to do repetitive work without encumbering source code. This relies on the compiler always unrolling these for loops. We found in #16596 that that isn't always the case. The actual reason why unrolling failed to happen in the case in #16596 is actually that I forgot a `static inline` on the shared implementation function for that ukernel; inlining it was necessary to reveal the constancy of the trip count and thus the unrollability. So technically, it might be enough to just add the missing `static inline`. But then, when we forget it, that silently degrades performance as it did here. By contrast, adding these `unroll(full)` pragmas causes a clang warning to be generated when the loop can't be unrolled, which is how I realized that I had forgotten the `static inline`. So as some layers of defense-in-depth against suboptimal compilation of ukernel code, this PR adds: 1. The missing `static inline` on those helper functions. 2. The `pragma unroll(full)` on all loops that should always be unrolled. 3. `attribute(always_inline)` on top of `static inline` on those functions that we really know should always be inlined and where failure to inline would lead to failure to unroll.
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 is still in its early phase. We have settled down on the overarching infrastructure and are actively improving various software components as well as project logistics. It is still quite far from ready for everyday use and is made available without any support at the moment. With that said, we welcome any kind of feedback on any communication channels!
See our website for more information.
IREE is licensed under the terms of the Apache 2.0 License with LLVM Exceptions. See LICENSE for more information.