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


##########
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.
   
   Any `attrs` can already be created in the `preprocessor` we have today, for 
example:
   
   
https://github.com/apache/tvm/blob/f6f90569bc893204c39f8a32a42612972a7d138f/src/target/target_kind.cc#L179
   
   As well as `keys` being attached as defaults on generation:
   
   
https://github.com/apache/tvm/blob/f6f90569bc893204c39f8a32a42612972a7d138f/src/target/target_kind.cc#L270
   
   > 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?
   
   We're parsing the entire `Target` using the `target_parser` here (as 
suggested by @junrushao1994 above), as part of parsing the `Target` we can 
parse the existing attributes and break them down into the various other 
attributes. That makes sense to me, do you have another suggestion? 



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