| commit | e36844f0894dc706e355bec31b33812e414d2f9f | [log] [tgz] |
|---|---|---|
| author | Nirvedh Meshram <96096277+nirvedhmeshram@users.noreply.github.com> | Mon Apr 15 15:54:54 2024 -0500 |
| committer | GitHub <noreply@github.com> | Mon Apr 15 15:54:54 2024 -0500 |
| tree | 7a92f028afab9da9ce9eb77be5362c6bf2f0a5b9 | |
| parent | 1d00b505de74455fc14175d2d3decdad180293f4 [diff] |
Add ability to call the same custom dispatch multiple times when using pdl patterns. (#16967) Following changes were made to allow multiple calls 1. In the rewriteAsFlowDispatch function we now check if the executable being created already exists and if it does we call that executable rather than creating a new one. 2. Adds a naming scheme to make unique executable names based on input/output types. 3. It was discovered that the created executable was not handling offsets correctly, the reason was the folder on memref.extract_stided_metadata op which would break the link between the offset and the function call before the offset was set. Further it was also noticed that the memref type did not have a MemRefLayoutAttr so it implicitly assumed zero offset. Now we add it to the memref type and assume the offset is dynamic at the time of executable creation so it wont get folded even with the incorrect folder from upstream. To further safeguard in case the offset gets optimized to zero and later changed we add a iree_codegen.extract_strided_metadata which is an extact replica of the memref dialect op with the exception that it does not have the incorrect folder. 4. Lastly we add a trivial pattern to convert iree_codegen.extract_strided_metadata to memref.extract_strided_metadata in IREEExpandStridedMetadata pass. It should be noted that the expectation is that the memref type should not say it has zero offset here if we dont have a zero offset. If the type says it has zero or any static offset, the upstream folder will still trigger and break the link to any consumers before our ResolveExtractMetadataFromHalInterfaceBindingSubspan pattern can resolve it.
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.