mbs-octoml edited a comment on pull request #9848:
URL: https://github.com/apache/tvm/pull/9848#issuecomment-1018779867
Hi @tqchen, yes things do indeed get subtle on function types! I tried to
capture that in the header mega-comment in device_planner.cc.
Inside the device planner we can talk about the 'device domain' for any
expression, including those of function type which describes the device domains
for the args and result separately. Ie the domain for planning is currently `D
:= (D,...,D) -> D | VirtualDevice`. And I declare (by fiat!) that the device
holding the function or closure is the same as the device on which the function
is executed which is the same as the device holding the functions result.
But when it comes time to the virtual_device field I'm not convinced it's
worth exposing this higher-order domain machinery, so the field just has
plain-old first order VirtualDevice.
So now we need a convention for what fn->virtual_device should be:
a. Leave it undefined -- you can't ask that question and must instead look
at the virtual_device for the function param vars and the body. I think that's
your suggestion also.
b. Set it to be the function's result device (and if the function returns
a function it's the result device of that function, etc. This corresponds to
the device planner's notion of 'result device'.) This was my suggestion to
Lily, hence this PR. This approach also allows us to assign a device to any
expression of function type (even though it may not be a function literal):
expr.virtual_device = result_device(expr.virtual_device_domain).
c. Bite the bullet and store some new VirtualDeviceDomain on every
expression instead of just VirtualDevice.
Wdyt?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
