Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/include/mlir/Dialect/GPU/IR/GPUOps.td | ||
---|---|---|
1062 | What kind of "information of how the object was generated" are stored and how? From the rest of the patches seems like it is "the binary string", period. | |
1070 | Can the target be defined as GPUTargetAttr? I'm also not sure it is a good idea to use a StringAttr here, it can be large storage that we could store differently than in the MLIRContext. Maybe it's good enough to start with and we can update later (I'm just worried it means we'll never get to it...) | |
1089 | We should document what is the objectManager role here. | |
1094 | the example syntax does not show the objectManager? | |
1102 | Shall we move the attr-dict-with-keyword after the objects? Also is the keyword needed? | |
mlir/lib/Dialect/GPU/IR/GPUDialect.cpp | ||
1551 | Why do you need this custom print/parse here? Edit: maybe it'll only be needed in a subsequent revision, in which case that's fine... |
mlir/include/mlir/Dialect/GPU/IR/GPUOps.td | ||
---|---|---|
1062 | It also stores GPUTargetAttr, which has the information on how the object was generated encoded in the method. Also the SelectObjectManager can use the attribute to select the appropriate target. | |
1070 | I think there's an 'egg-chicken' dependency with ObjectManagerAttrInterface if we have it use BinaryOp, but I'll come back with a better answer. I used StringAttr because the old pipeline uses StringAttr, however we can create a new parameter type that stores strings as smart ptrs? | |
mlir/lib/Dialect/GPU/IR/GPUDialect.cpp | ||
1551 | Yes, this is changed in D154147 with the introduction of the SelectObjectManager as the default one. |
mlir/include/mlir/Dialect/GPU/IR/GPUOps.td | ||
---|---|---|
1089 | I'll add it. | |
1094 | In change that in D154147, I didn't want to introduce a name of something that is not there (SelectObjectManager). | |
1102 | With keywords is not needed. I put it before $objects, because $objects can be thousands of characters long so if they are before, it's easier to edit them by hand. |
mlir/include/mlir/Dialect/GPU/IR/GPUOps.td | ||
---|---|---|
1062 | oh I see the "information of how the object was generated" applies to the whole pair and not the binary string. I think I misread this... | |
1070 | We should have a "StringAttrInterface" ;) | |
1070 | (this is far out of scope to create such interface of course) | |
1102 | makes sense! |
Switched ObjectManager to BinaryHandler.
Switched the types of the parameters from generic Attributes to the respective interface in gpu.object & gpu.binary.
mlir/include/mlir/Dialect/GPU/IR/GPUOps.td | ||
---|---|---|
1089 | It's not documented yet? |
Update the gpu.binary attributes to use OffloadingTranslationAttrTrait
instead of OffloadingLLVMTranslationAttrInterface.
What kind of "information of how the object was generated" are stored and how? From the rest of the patches seems like it is "the binary string", period.