| commit | e7fad8193e982cea4cf2658725522f4bfe53d06d | [log] [tgz] |
|---|---|---|
| author | Max191 <44243577+Max191@users.noreply.github.com> | Tue Jul 30 10:26:46 2024 -0700 |
| committer | GitHub <noreply@github.com> | Tue Jul 30 13:26:46 2024 -0400 |
| tree | e96afe2754db7e81ba17f4795bafc85388694465 | |
| parent | 7361340b62ecc37a685a8c6bc4b0fec58ddbf3ba [diff] |
[Encoding] Add an optional bcast_map attribute to EncodingAttr. (#18032) This adds a new optional field to encodings called `bcast_map`. When we set encodings, we want to set encodings on the inputs to broadcasting operations, since it is less data to pack. This `bcast_map` is a step towards being able to do this, since it is needed in order to know which dimensions of the tensor correspond to which dimensions of the packed layout. The new field is an affine map that encodes which dimensions of the encoded tensor map to which dimensions in the corresponding operand of the data tiled op. For example, if the LHS of a matmul is broadcasted along the batch dimension, and we set encoding on the input to the broadcast: ```mlir #map = affine_map<(d0, d1, d2) -> (d1, d2)> #map1 = affine_map<(d0, d1, d2) -> (d0, d1, d2)> %se = iree_encoding.set_encoding %lhs : tensor<4x16xf32> -> tensor<4x16xf32, ... bcast_map = #map %bcast = linalg.broadcast ins(%lhs ... outs(%e : tensor<2x4x16xf32, ... bcast_map = #map1 ... dimensions = [0] ``` The result of the broadcast, which will be consumed by the matmul, has an identity broadcast map, and the input to the broadcast has a broadcasted affine map. The `#map` says that the dimensions of `%se` correspond to `d1` and `d2` in the LHS of the matmul that consumes `%bcast`. In cases where we transpose narrow N matmuls, the `bcast_map` remains the same. Handling this properly is left as a TODO, to be fixed when more pieces land, and we can more properly test transposed narrow N matmuls. This is okay for now, since the `bcast_map` is not actually used anywhere yet. Signed-off-by: hanhanW <hanhan0912@gmail.com> Co-authored-by: hanhanW <hanhan0912@gmail.com>
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.
Community meeting recordings: IREE YouTube channel
IREE is licensed under the terms of the Apache 2.0 License with LLVM Exceptions. See LICENSE for more information.