[ESI] Add AppID design hierarchy manifest data to the manifest #6345
Conversation
This makes for far more sensible hierarchies.
Mirrors the AppID index hierarchy. Clone manifest data into it.
|
zlib is really good at compressing JSON:
It was so small, I actually verified it with Python's zlib library! |
| @@ -112,6 +113,10 @@ def ServiceImplRecordOp : ESI_Op<"esi.manifest.service_impl", [ | |||
| qualified($appID) (`svc` $service^)? `by` $serviceImplName `with` $implDetails | |||
| attr-dict-with-keyword $reqDetails | |||
| }]; | |||
|
|
|||
| let extraClassDeclaration = [{ | |||
| void getDetails(SmallVectorImpl<NamedAttribute> &results); | |||
There was a problem hiding this comment.
'getDetails' is pretty vague to me - referencing the summary, does this mean that the details are the "information necessary to connect to the service and service clients"? - it probably should have a comment.
There was a problem hiding this comment.
This method is part of the IsMetadata OpInterface and is described there... in not too much more detail.
| @@ -89,6 +89,7 @@ def ServiceRequestRecordOp : ESI_Op<"esi.manifest.req", [ | |||
| AppIDAttr getAppID() { | |||
| return getRequestor(); | |||
| } | |||
| void getDetails(SmallVectorImpl<NamedAttribute> &results); | |||
| @@ -131,6 +136,10 @@ def ServiceImplClientRecordOp : ESI_Op<"esi.manifest.impl_conn", [ | |||
| $relAppIDPath `req` $servicePort `(` $bundleType `)` | |||
| `with` $implDetails attr-dict | |||
| }]; | |||
|
|
|||
| let extraClassDeclaration = [{ | |||
| void getDetails(SmallVectorImpl<NamedAttribute> &results); | |||
| // Manifest ops. | ||
| //===----------------------------------------------------------------------===// | ||
|
|
||
| StringRef ServiceImplRecordOp::getManifestClass() { return "service"; } |
There was a problem hiding this comment.
can these raw strings be moved to some named constants?
There was a problem hiding this comment.
They're not (as of now) used in any other part of the code -- they simply appear in the manifest. So I don't think that warrants a named constant.
| // Gather the relevant types. | ||
| mod->walk([&](Operation *op) { scrapeTypes(op); }); | ||
| // Find the top level appid hierarchy root. | ||
| for (auto root : mod->getRegion(0).front().getOps<AppIDHierRootOp>()) |
There was a problem hiding this comment.
Operation *mod = getOperation(); -> mlir::ModuleOp mod = getOperation(); since you anyways restricting pass scheduling at that level.
Then you don't need this getRegion(0).front() but can just refer to the body block.
There was a problem hiding this comment.
I'm trying to write code that is resilient to future changes in the outer container (the coming hw.design outer container).
Serialize the IR representation into JSON as part of the manifest.