areusch commented on code in PR #71:
URL: https://github.com/apache/tvm-rfcs/pull/71#discussion_r894710428


##########
rfcs/0071-target-json-parser.md:
##########
@@ -0,0 +1,172 @@
+- Feature Name: target-json-preprocessor
+- Start Date: 2022-04-04
+- RFC PR: [apache/tvm-rfcs#0071](https://github.com/apache/tvm-rfcs/pull/71)
+- GitHub Issue: [apache/tvm#0000](https://github.com/apache/tvm/issues/0000)
+
+# Summary
+[summary]: #summary
+Extend the existing `TargetKind` `preprocessor` to allow preprocessing of the 
entire `Target` JSON representation rather than just `attrs`.
+
+# Motivation
+[motivation]: #motivation
+
+Taking an example `Target` in JSON form:
+
+```js
+{
+    "id": "cuda",
+    "tag": "nvidia/tx2-cudnn",
+    "keys": ["cuda", "gpu"],
+    "libs": ["cudnn"],
+    "target_host": {
+        "id": "llvm",
+        "system_lib": True,
+        "mtriple": "aarch64-linux-gnu",
+        "mattr": "+neon"
+    }
+}
+```
+
+We can see that there are additional fields which are of interest to TVM, 
note-ably `keys` and `libs` which we currently do not apply parsing to on 
`Target` instantiation. Extending the `TargetKind` `preprocessor` beyond 
`attrs` enables to customise parsing of the entire `Target`, enabling the 
values passed by the user to be used to infer other properties used during 
compilation.

Review Comment:
   i think the wording here is a bit confusing. Do you mean to say "We can see 
there are additional fields used internally within TVM that can be inferred 
from a smaller set of user-facing fields. Currently, users are required to 
understand TVM internals to know how to set these additional fields. Extending 
the `TargetKind` `preprocessor` ..."



##########
rfcs/0071-target-json-parser.md:
##########
@@ -0,0 +1,172 @@
+- Feature Name: target-json-preprocessor
+- Start Date: 2022-04-04
+- RFC PR: [apache/tvm-rfcs#0071](https://github.com/apache/tvm-rfcs/pull/71)
+- GitHub Issue: [apache/tvm#0000](https://github.com/apache/tvm/issues/0000)
+
+# Summary
+[summary]: #summary
+Extend the existing `TargetKind` `preprocessor` to allow preprocessing of the 
entire `Target` JSON representation rather than just `attrs`.
+
+# Motivation
+[motivation]: #motivation
+
+Taking an example `Target` in JSON form:
+
+```js
+{
+    "id": "cuda",
+    "tag": "nvidia/tx2-cudnn",
+    "keys": ["cuda", "gpu"],
+    "libs": ["cudnn"],
+    "target_host": {
+        "id": "llvm",
+        "system_lib": True,
+        "mtriple": "aarch64-linux-gnu",
+        "mattr": "+neon"
+    }
+}
+```
+
+We can see that there are additional fields which are of interest to TVM, 
note-ably `keys` and `libs` which we currently do not apply parsing to on 
`Target` instantiation. Extending the `TargetKind` `preprocessor` beyond 
`attrs` enables to customise parsing of the entire `Target`, enabling the 
values passed by the user to be used to infer other properties used during 
compilation.
+
+# Guide-level explanation
+[guide-level-explanation]: #guide-level-explanation
+
+Alongside the existing `set_attrs_preprocessor` method on `TargetKind`, there 
will be an alternative `set_target_parser` method, this new parser will take 
precedence over the `attrs` preprocessor if present:
+
+```c++
+TVM_REGISTER_TARGET_KIND("target", kDLCPU)
+    .set_target_parser(TargetParser);
+```
+
+The canonical JSON form of `Target` will be passed to the new `Target` parser 
and the parser will return the transformed variant in JSON form for further 
steps:

Review Comment:
   ```suggestion
   The canonical JSON form of `Target` will be passed to the new `TargetParser` 
and the `TargetParser` will return the transformed variant in JSON form for 
further steps:
   ```
   
   do we consider the returned JSON to also be canonical?



##########
rfcs/0071-target-json-parser.md:
##########
@@ -0,0 +1,172 @@
+- Feature Name: target-json-preprocessor
+- Start Date: 2022-04-04
+- RFC PR: [apache/tvm-rfcs#0071](https://github.com/apache/tvm-rfcs/pull/71)
+- GitHub Issue: [apache/tvm#0000](https://github.com/apache/tvm/issues/0000)
+
+# Summary
+[summary]: #summary
+Extend the existing `TargetKind` `preprocessor` to allow preprocessing of the 
entire `Target` JSON representation rather than just `attrs`.
+
+# Motivation
+[motivation]: #motivation
+
+Taking an example `Target` in JSON form:
+
+```js
+{
+    "id": "cuda",
+    "tag": "nvidia/tx2-cudnn",
+    "keys": ["cuda", "gpu"],
+    "libs": ["cudnn"],
+    "target_host": {
+        "id": "llvm",
+        "system_lib": True,
+        "mtriple": "aarch64-linux-gnu",
+        "mattr": "+neon"
+    }
+}
+```
+
+We can see that there are additional fields which are of interest to TVM, 
note-ably `keys` and `libs` which we currently do not apply parsing to on 
`Target` instantiation. Extending the `TargetKind` `preprocessor` beyond 
`attrs` enables to customise parsing of the entire `Target`, enabling the 
values passed by the user to be used to infer other properties used during 
compilation.
+
+# Guide-level explanation
+[guide-level-explanation]: #guide-level-explanation
+
+Alongside the existing `set_attrs_preprocessor` method on `TargetKind`, there 
will be an alternative `set_target_parser` method, this new parser will take 
precedence over the `attrs` preprocessor if present:

Review Comment:
   ```suggestion
   Alongside the existing `set_attrs_preprocessor` method on `TargetKind`, 
there will be an alternative `set_target_parser` method. This new parser will 
take precedence over the `attrs` preprocessor if present:
   ```



##########
rfcs/0071-target-json-parser.md:
##########
@@ -0,0 +1,172 @@
+- Feature Name: target-json-preprocessor
+- Start Date: 2022-04-04
+- RFC PR: [apache/tvm-rfcs#0071](https://github.com/apache/tvm-rfcs/pull/71)
+- GitHub Issue: [apache/tvm#0000](https://github.com/apache/tvm/issues/0000)
+
+# Summary
+[summary]: #summary
+Extend the existing `TargetKind` `preprocessor` to allow preprocessing of the 
entire `Target` JSON representation rather than just `attrs`.
+
+# Motivation
+[motivation]: #motivation
+
+Taking an example `Target` in JSON form:
+
+```js
+{
+    "id": "cuda",
+    "tag": "nvidia/tx2-cudnn",
+    "keys": ["cuda", "gpu"],
+    "libs": ["cudnn"],
+    "target_host": {
+        "id": "llvm",
+        "system_lib": True,
+        "mtriple": "aarch64-linux-gnu",
+        "mattr": "+neon"
+    }
+}
+```
+
+We can see that there are additional fields which are of interest to TVM, 
note-ably `keys` and `libs` which we currently do not apply parsing to on 
`Target` instantiation. Extending the `TargetKind` `preprocessor` beyond 
`attrs` enables to customise parsing of the entire `Target`, enabling the 
values passed by the user to be used to infer other properties used during 
compilation.
+
+# Guide-level explanation
+[guide-level-explanation]: #guide-level-explanation
+
+Alongside the existing `set_attrs_preprocessor` method on `TargetKind`, there 
will be an alternative `set_target_parser` method, this new parser will take 
precedence over the `attrs` preprocessor if present:
+
+```c++
+TVM_REGISTER_TARGET_KIND("target", kDLCPU)
+    .set_target_parser(TargetParser);
+```
+
+The canonical JSON form of `Target` will be passed to the new `Target` parser 
and the parser will return the transformed variant in JSON form for further 
steps:
+
+```c++
+using TargetJSON = Map<String, ObjectRef>;
+TargetJSON TargetParser(TargetJSON target) {
+    // ... transforms ...
+    return target;
+}
+```
+
+The parser will have to be capable of handling the diversity of types of 
`Target` in TVM, therefore the underlying mechanism of the parser is left as an 
implementation detail. Using the example of pre-processing the `keys` attribute 
(used for detecting appropriate schedules), it can be seen how this can apply 
to various `Target`s. 

Review Comment:
   not sure I quite understand this. at present there is just `Target`, right? 
and a `TargetParser` is registered to a particular `Target` kind. could you 
elaborate?



-- 
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]

Reply via email to