tree 368da939f11e0d0389469bb195eae66c3c88d6e7
parent e768c17f8c6ee10c59be9d88051d9d4fa61d4e58
author bjacob <benoitjacob@google.com> 1680537881 -0400
committer GitHub <noreply@github.com> 1680537881 +0000
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsBcBAABCAAQBQJkKvkZCRBK7hj4Ov3rIwAAVToIAG4ai29TMBq8UuRbBmV1Oc+m
 m7Wzoqtt3+8VzP0Gv3jXmwnTxxLZMB6uhZkwBFvzJ4ayr6coPD95Zs6OKvfrcWFX
 D/4AHi3CeAh/RjCoCP/FWOELzTaP1upH/QvvQPN2HPmlNQQhVG+wxFxFz8jire4E
 pNse2ZakDeaE/sXeGmRQLUD1nNrhUr7vnF2GAIw690BlUZ0N5OmsX68tQVBLEQRi
 In8siflq+qG8wU40kpGLC4ThqS1QaBJPGS9xaG6o2EIQKHzkLXl7G6/1OO2QHEkM
 KTvXKsMFLPVou61I2nbndNK/UKYOVl6jDvAaT7s3CFub5yjMrvVoRiOiONrUmpU=
 =MYph
 -----END PGP SIGNATURE-----
 

e2e matmul benchmark as standalone C calling pack, mmt4d, unpack ukernels (#12848)

(This is take-2 of #12818). This is equivalent to compiling a
`linalg.matmul` with data-tiling and ukernels enabled and benchmarking
the resulting module, but as a standalone C program directly calling the
ukernels, it's trivially optimal in all sorts of way that the full-blown
iree-compile-based flavor isn't at the moment. It can be useful to
quickly evaluate potential performance if all sorts of issues were
fixed, and with profiling it can help answer questions of how much
packing/unpacking overhead is inherent in the data-tiling approach.