This removes the need to define the derived Operand class before the derived
Value class. The major benefit of this refactoring is that we no longer need
the OpaqueValue class, as OpOperand can now be defined after Value. As part of
this refactoring the BlockOperand and OpOperand classes are moved out of
UseDefLists.h and to more suitable locations in BlockSupport and Value. After
this change, UseDefLists.h is almost entirely composed of generic use def utilities.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
This is really great River, thank you and nice work!
mlir/include/mlir/IR/BlockSupport.h | ||
---|---|---|
37 | Nit: "in the BlockOperand list of the Operation". Unrelated to your patch, but I think we should expunge the term "User" from the MLIR IR definition (e.g. the getUser() method in ValueUseIterator). This is an LLVM term that we outgrew. I think it would be better to just use the word "getOperation()" instead of getOwner() / getUser(). | |
mlir/include/mlir/IR/Value.h | ||
258 | nit User -> Operation |
Thanks for the review!
mlir/include/mlir/IR/BlockSupport.h | ||
---|---|---|
37 | The problematic part of removing the User part to me is what to do with the getUsers API. Would Value::getUsers turn into Value::getOperations? I can see that being confusing, i.e. does that include the parent op? +1 on changing getOwner though. |
mlir/include/mlir/IR/BlockSupport.h | ||
---|---|---|
37 | Good point, I'd keep getUsers() named as it is. The key thing there is that "user" is a description of a class of operation that "use" the value, so the name is appropriate. |
Nit: "in the BlockOperand list of the Operation".
Unrelated to your patch, but I think we should expunge the term "User" from the MLIR IR definition (e.g. the getUser() method in ValueUseIterator). This is an LLVM term that we outgrew. I think it would be better to just use the word "getOperation()" instead of getOwner() / getUser().