commit | ca695fe9b672c75f72dc5f05c3817eb547cf890e | [log] [tgz] |
---|---|---|
author | Eric Lunderberg <Lunderberg@users.noreply.github.com> | Fri Jul 15 16:47:23 2022 -0500 |
committer | GitHub <noreply@github.com> | Fri Jul 15 14:47:23 2022 -0700 |
tree | cee8bdc934346725694daeb8be8a58fac2ced4de | |
parent | 22d1d11ec0352131fccab58ee2ee5a912ec88dfc [diff] |
[RFC] Buffer Layout Padding (#77) * [RFC] Buffer Layout Padding This RFC introduces a method to specify padding to be applied as part of a buffer layout transformation, to be used when the desired layout does not evenly tile the buffer being transformed, and simplifications that can be performed based on these padded buffers. The motivating examples are primarily in the "Implementation options" section, which goes through several desired usages of the buffer padding, and how they can be automatically derived using the TIR primitives/transformations described in earlier sections. * Updated number to match PR, added RFC PR link. * Fixed erroneous lack of Chris Sullivan on author list * Rename builtin::arbitrary to builtin::undef Following @wrongtest's suggestion at https://github.com/apache/tvm-rfcs/pull/77#discussion_r890708951. * Change sequential_buffer_access from a primitive to a utility Following suggestion from @Hzfengsy at https://github.com/apache/tvm-rfcs/pull/77#discussion_r890799432 * Updated to use T.assume everywhere, instead of BufferConstraint * Added description of what may be necessary for split/hoisted stage * Removed if statement in example * Added reference to LLVM's __builtin_assume. * Updated from discussion, when a PrimFunc's interface may be altered * Updated table of contents and internal links * Wording change on PrimFunc interface changes * Added transformation rules on T.assume from discussion * Removed trailing whitespace * Corrected mistake in MergeConditionals example
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.