support of multiple devices for tvm.build#1773
Conversation
2677b14 to
8462167
Compare
|
Ref. RFC #1242
Here the device_types is selected based on the result of How about another PR first to demonstrate the fallback behavior of operator and copy insertion before integrating nnvm build to tvm build. |
|
Or I can remove the compiler related stuff now, but only keep the new |
|
Thanks @zhiics Yes, different PR after with Fallback mechanism followed by integrating it to TVM build makes easy to understand the end to end flow while review. |
| for devices coupled with target information. | ||
|
|
||
| There are two typical uses of this functioin: | ||
| 1. For backward compatibility |
There was a problem hiding this comment.
This is a valid case of usage so we don't want to see for backward compatiblity.
Consider put these code examples under Example section with rst real code block
| return ir_pass.MakeAPI(stmt, name, arg_list, 0, cfg.restricted_func) | ||
|
|
||
|
|
||
| def build(sch, |
There was a problem hiding this comment.
Let us rename sch to inputs, since now it is more than a scheduld
| raise ValueError("Duplicate function name %s" % x.name) | ||
| fname_set.add(x.name) | ||
|
|
||
| fhost_all = [] |
There was a problem hiding this comment.
Let us move the older per device logic to a separate internal function
8558960 to
e18c0d3
Compare
|
Thanks @srkreddy1238 @zhiics , this is now merged |
This PR mainly focuses on supporting multiple devices for
tvm.build, it is part of #1688.The proposal 2 of #1752 is implemented to support multiple devices for compilation and code generation. In the end, only one module will be generated. (In compiler PR, in order to pass
target: loweredfunc_listpairs totvm.build, we need to slightly modify theGraphCompliepass. Multiple targets need to be glued to the graph for compiling, and adevice_typefield may need to be added toNodeAttrorOp. )