| commit | 129ae96d48966bd6b0f2e7d7fd7674a72e06f59d | [log] [tgz] |
|---|---|---|
| author | Han-Chung Wang <hanchung@google.com> | Thu Dec 01 06:29:31 2022 +0800 |
| committer | GitHub <noreply@github.com> | Wed Nov 30 22:29:31 2022 +0000 |
| tree | 45a47be5a031ee884fba2423fb2e2002c853e39e | |
| parent | 2f4225dbb33132eb9d583e322ac51fac9f9eb2ef [diff] |
Enable fusion for elementwise Linalg op + pack op (#11374) It also updates the LinalgExtVectorization to use tile+fuse, so we can tile+fuse the generic ops. Some metric data w/ mobilebert fp32: The number of dispatches: - Legacy mmt4d: 39 - data tiling w/o fusion: 57 - data tiling w/ pack fusion: 59 It's reasonable for having more different dispatches because some of different set_encoding ops could be folded into same producer dispatches. E.g., we could have dispatch_A, LHS_encoding, RHS_encoding in the beginning. After more aggressive fusion, we could get `dispatch_A + LHS_encoding` + `dispatch_A + RHS_encoding` + `LHS_encoding` + `RHS_encoding`. There would be 4 dispatches after fusion. We should use the metric about the number of kernel launch. The number of `flow.dispatch` launch: - Legacy mmt4d: 1980 - data tiling w/o fusion: 2871 - data tiling w/ pack fusion: 2750 The legacy mmt4d path has less kernel launches because 1. Need unpack op fusion, which is WIP. 2. Propagation helps better fusion. 3. We don't have canonicalization patterns for packing on constant. I verified that (3.) can save 361 times of kernel launch, tracking in https://github.com/iree-org/iree/issues/11360 Relands https://github.com/iree-org/iree/pull/11284 with fixes for mid-air collision.
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.