commit b35c97f3c23e1d85554f1dea50a0ef740c22c934
author bjacob <benoitjacob@google.com> Fri Nov 25 15:17:37 2022 +0000
committer GitHub <noreply@github.com> Fri Nov 25 10:17:37 2022 -0500
tree 3db884071670c6426e2da7abcf7b9ae4b6810210
parent 7ec09ce9c21c3193a675f6bc0737f63b8ac32915

Allow encoding info to depend on elem type and target info. (#11290)

This makes it an implementation detail of the `MaterializeEncodingFn` to
actually use target info and element type to determine real (useful)
tile sizes. See how the `iree/compiler/` side does a
`IREE::HAL::ExecutableTargetAttr::lookup` from #11057 to get the
`target` attribute. Meanwhile, #11291 will make it easy to obtain the
details that we need based on that attribute (the existing codebase is
still wired to deal with `ExecutableVariantOp`'s, needs to be adapted
post #11057).

The element type is passed as a function argument, while the target info
is not. Accordingly, when we want to actually depend on target info, at
the place where we construct a `MaterializeEncodingTypeConverter`
passing it a `MaterializeEncodingFn`, we can pass a function that itself
depends on target info, as exemplified in this PR by the IREE side
change where we pass a lambda capturing `getOperation()`.

Motivation for this compromise:

- TLDR: minimize PR size.
- Long version: If `MaterializeEncodingFn` itself takes an `Operation*`
then we need to be able to pass that in the `getMaterializedType` call
in the lambda passed to `addConversion` in the the constructor of
`MaterializeEncodingTypeConverter`. Fine then, we could have the
`MaterializeEncodingTypeConverter` constructor take `getOperation()` as
argument, and propagate that all the way down to places where
`MaterializeEncodingFn` is called. This works, but results in a ~ 2x
bigger PR. In particular, chains of helper functions calling each other,
such as `getPackedDimsForDispatchTensor` and
`getPackedDynamicDimsForDispatchTensor`, which currently take a
`Location`, would now also need to take `Operation*`, and I was starting
to wonder whether to drop the `Location` argument, and how I would
document what these functions really do with their parameters (if we
drop the `Location` arg, then the `Operation*` arg becomes more than
just target-information, and it becomes nontrivial to describe its role
in this function's semantics).