Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge main -> google #5078

Merged
merged 18 commits into from
Mar 12, 2021
Merged

Conversation

ThomasRaoux
Copy link
Contributor

benvanik and others added 16 commits March 10, 2021 17:56
Would be really, really nice to have an ASAN bot.
shapex.tie_shape now implements this interface and is no longer checked
for specifically. This allows any op to carry ranked shape-compatible
information. Its usage is kind of like ViewLikeOpInterface in that the
op stores the dynamic dimensions and can return them as needed via the
interface.
This removes most of the tie_shape uses outside of dispatch regions.
It required reworking ClosureOpDce so that the shape-aware ops can still
be optimized. Future changes will start edging us towards handling
shapes with this interface such that the ties are only required when
interoping with code that is not shape-aware.
The ClosureOpInterface canonicalizer does this now.
This avoids any globs of source files in CMake (which are
[discouraged](https://cmake.org/cmake/help/latest/command/file.html#glob))
and any globs being evaluated in bazel_to_cmake (which would make it
depend on files other than the BUILD file). It still allows the safety
check that you actually included all the files you meant to (which is
particularly useful with tests, where a failure to do so is test
skipped forever instead of an immediate build failure). The cost is
having to explicitly list a new source file when you add it, which
seems not so bad.

I didn't remove bazel_to_cmake support for glob yet, so I can clean up
any stragglers after this lands.

Fixes iree-org#1083
…ups (iree-org#4999)

This commit adds all necessary plumbing to connect 2-D convolution
and matmul vectorization inside flow.dispatch.workgroups. This includes:

* Let 2-D convolution be recognized as a root op during dispatch
  region formation.
* Add a pass to concretize the abstract tiling and distribution
  during flow dispatch region formation. It substitutes symbolic
  ops with concrete values from CodeGen policy.
* Recognize `hal.interface.workgroup.id` ops when folding GPU
  processor ID uses.
* Recognize `hal.interface.binding.subspan` when vectorizing
  `memref`s for better memory access.

Along the way, the old path is refactored to have a better structure
for further cleaning up:

* `LinalgTileAndDistributePass` is split out of `LinalgTileAndFusePass`.
  It will be used for tiling and distribution among workgroups in the
  old path. `LinalgTileAndFusePass` will be for tiling and vectorization
  in a single workgroup (and it will be renamed later).
* A few tests are updated to use the new path.
This allows for results of operations to be tied back to their
operands in storage but not in time. This allows for in-place
operations to be defined on tensors that carry enough metadata
to be able to correctly form streams, materialize HAL
interfaces, and allocate buffers.

Example:
```mlir
%t = flow.dispatch @foo[...](%input) : (tensor<4xf32>) -> %input
```

This syntax also combines with the shape-carrying op interface
to make it possible to also indicate that an input and a result
share type and shape information:
```mlir
%t = flow.dispatch @foo[...](%input) : (tensor<?xf32>{%dim}) -> %input
```
which is effectively:
```mlir
%t = flow.dispatch @foo[...](%input) : (tensor<?xf32>{%dim}) -> tensor<?xf32>{%dim}
```
but with the extra bit that result 0 is tied to operand 0.

Here the result %t of the dispatch aliases the storage for %input,
making %input a read-write/mutable binding in the resulting HAL
executable. %t is a distinct SSA value from %input, though, and
represents the value of the storage backing %input after the
dispatch has completed. By keeping the SSA use-def chains correct
with respect to time they are still meaningful for analysi2As and
nothing at this level (and the beginning of the HAL transformations)
needs to perform alias analysis, while still giving us all of the
information required to induce aliasing during later allocation
passes.
asaadaldien and others added 2 commits March 11, 2021 17:59
- Note the approximations don't have finite math assumption, so they are
on by default.
@copybara-service copybara-service bot merged commit c9e5da3 into iree-org:google Mar 12, 2021
hanhanW pushed a commit to hanhanW/iree that referenced this pull request Mar 12, 2021
* c9e5da3 Merge pull request iree-org#5078 from ThomasRaoux:main-to-google
* 284e68c Synchronize submodules with LLVM at llvm/llvm-project@720a828
* c0ae7a2 Integrate LLVM at llvm/llvm-project@720a828
* 0aebce2 Merge pull request iree-org#5062 from ThomasRaoux:main-to-google
* 56e4fd1 Merge pull request iree-org#5060 from google:llvm-dependent-submodule-update
* 0f70af6 Integrate LLVM at llvm/llvm-project@4c973ae
* f156c24 Synchronize submodules with LLVM at llvm/llvm-project@4c973ae
* 894c758 Synchronize submodules with LLVM at llvm/llvm-project@df6d057
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants