commit | b675ef8e74351f298b8f3bc4ae944eaf3cbbe430 | [log] [tgz] |
---|---|---|
author | Eric Lunderberg <Lunderberg@users.noreply.github.com> | Thu Feb 17 11:37:13 2022 -0600 |
committer | GitHub <noreply@github.com> | Thu Feb 17 09:37:13 2022 -0800 |
tree | 880ef04ae6c59e0acff755c6b0563150962a1445 | |
parent | d9dd6eb5e522ff169fe3bf4f5b9c5c3e84d95145 [diff] |
[RFC][TIR] Layout transformations on buffer access (#39) * [RFC][TIR] Separate physical and logical layout of buffers * Updated with link to the PR * Fixed typo in example * Added link to RFC#0040. * Updated version with a function to define the physical layout. * Updated with reference to iter_affine_map.h * Updated following TQ's suggestions. * Updated with link to BufferPointer RFC * Updated following some comments from @vinx13 * Added description of the BufferTransform node. * Added details on te.AXIS_SEPARATOR * Updated buffer transformations to be in the PrimFunc::attrs * Added author list, Eric/Wuwei * Clarifying updates following comments from @areusch * Remove reference to RFC#0042 Since we decided against RFC#0042, the reference is no longer needed here. * Updated with examples of returned loop iterators. Also, removed implementation details that didn't match the implementation. A new stage wasn't necessary, and the loop iterators could instead be updated in the existing stage, similar to `fuse()` and `split()`. * Updated examples of buffer flattening to have valid shape/indices. Initial example used a buffer shape of `[2,3]`, which was smaller than the indices used in the example. * Added discussion on buffer index conventions. * Typo, forgot to end a sentence. * Typo fixup, plus integrating in the conclusions from comments.
An RFC is a “Request for Change” to the TVM project. It is a design document that describes a new feature, enhancement, or process to the TVM project. RFCs should be the primary mechanism for proposing major features and changes. The author of the RFC is responsible for the discussion of the change, and for organizing the work around it. RFCs are text files, stored in the Apache TVM RFC repository, that serve as history and documentation of TVM features.
The primary audience of RFCs is the TVM development community. RFCs serve as a guide for the design and implementation of features during and after their development. A secondary audience is general users and developers who are interested in how and why a feature was designed and implemented.
To work on a major feature within the TVM project, an RFC must first be merged into the TVM RFC repository as a markdown file. Once merged, the RFC is considered to be “active” and may be implemented, with the goal of merging the implementation into the TVM project. These are steps that should be taken in the RFC process:
tvm-rfcs
repository. To allocate a new RFC number, open a PR against tvm-rfcs
(initially, you might need to use a dummy number in the filename for the RFC content; this can be updated after the RFC PR is created).L
to indicate it is a legacy RFC. For example, L0001
.Apache TVM is a compiler stack for deep learning systems. It is designed to close the gap between the productivity-focused deep learning frameworks, and the performance- and efficiency-focused hardware backends. TVM works with deep learning frameworks to provide end to end compilation to different backends.
© Contributors Licensed under an Apache-2.0 license.
TVM adopts Apache committer model. We aim to create an open source project that is maintained and owned by the community. Check out the Contributor Guide.