You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tvm.apache.org by GitBox <gi...@apache.org> on 2022/07/11 21:17:02 UTC

[GitHub] [tvm-rfcs] areusch commented on a diff in pull request #71: Add Target Pre-processing RFC

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


##########
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:
   i think the point is that canonical means there is only one and i'd think the canonical form would be the one returned by the parser. no?



##########
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:
   ah, so should we say kinds instead of types?



##########
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:
   yep, ok I think we're in agreement here, but the confusing bit is where each of those fields comes from--i think prior to this RFC, those fields all have to be supplied by the user. after this RFC, the idea is a preprocessor fills them, right? so the confusing thing about this sentence to me is the word "parsing," because we wouldn't be extending parsing of those attributes--we'd be generating them based on the ones we parsed out. does that makes sense to you?



-- 
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: commits-unsubscribe@tvm.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org