tree 3db884071670c6426e2da7abcf7b9ae4b6810210
parent 7ec09ce9c21c3193a675f6bc0737f63b8ac32915
author bjacob <benoitjacob@google.com> 1669389457 +0000
committer GitHub <noreply@github.com> 1669389457 -0500
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsBcBAABCAAQBQJjgNyRCRBK7hj4Ov3rIwAAfoEIAGOVwr41/KiN3oLe28kaj2tW
 BN0n85x7PuNa4Vs+E45AxuAEVYvtbZunlvkyCbO3rBK2jBXFEUjQRZm8boXYsb/9
 HbgGlSxKfg7yQ2WjoqidNhG/OAfmFLhGO2qKyDlpDBUB7+ejx59ovp3+Q5+IguGe
 y1NTKTcYCdUV+Qb6xhTB+rDGrnQW0LALrKDgR6I7NtwcjkdVlYgjtNESX/+oPiOI
 vfw/L6LgQRgBDpObaWsaE0Yzb/f+FZyCdm+mr2IYLgjohG6RwFn1ChxyE2fSBiUC
 o0GD1yu3WdoqZJSjHjpkxbQ7qsSgbGUoVAvRoVKW2sB5gD/ol2dCHNposBE+rxA=
 =BwUV
 -----END PGP SIGNATURE-----
 

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).