Finally time. We need functions that support tied operands and inlining control as today func.func has no good way to do it. We don't need shape/size-aware operands/results as IPO takes care of that in general and we don't want to require result sizes to be computable by callers.
When we have our own version we can control inlining; today the inliner control is handled by the func dialect so we can't do alwaysinline/noinline, can't avoid inlining into different device-scoped contexts, and can't add our own cost modeling for whether inlining is profitable.
We don't support function addresses today so we can ignore those ops and just bring over func.func/func.call as util.func/util.call.
[ ] identify places that can utilize tied operands (allocation, IPO, refinement, etc)
[ ] new pass (or in IPO?) to tie operands on funcs based on all call sites
[x] convert to util.func as part of the input pipeline (and update all tests)
[ ] implement inlining policy on hal.device.targets/stream.affinity to validate interface
Most of the func.func->util.func changes landed as part of #16411. There's still work to do to make use of the new util.func tied operand feature and enable IPO to work with it but that will come later.
Finally time. We need functions that support tied operands and inlining control as today func.func has no good way to do it. We don't need shape/size-aware operands/results as IPO takes care of that in general and we don't want to require result sizes to be computable by callers.
When we have our own version we can control inlining; today the inliner control is handled by the func dialect so we can't do alwaysinline/noinline, can't avoid inlining into different device-scoped contexts, and can't add our own cost modeling for whether inlining is profitable.
We don't support function addresses today so we can ignore those ops and just bring over func.func/func.call as util.func/util.call.