Integrate llvm-project@587d6fcbb685e3a57 #20948
Conversation
Signed-off-by: hanhanW <hanhan0912@gmail.com>
Signed-off-by: hanhanW <hanhan0912@gmail.com>
hanhanW
requested review from
qedawkins,
MaheshRavishankar,
IanWood1,
kuhar,
Groverkss and
antiagainst
as code owners
|
Expose the visibility for others on future integration duties: #20645 (comment) (and the following comment in the issue) provide the idea to drop the last revert. I don't have enough cycles to implement it. I can come back to it maybe after 2 weeks. I can prioritize it or provide guidance if it becomes a blocker. |
| @@ -45,7 +45,9 @@ static LogicalResult captureUsedOperationsAndBlockArguements( | |||
| auto yieldOp = cast<linalg::YieldOp>(linalgOp.getBlock()->getTerminator()); | |||
| Value result = yieldOp.getOperand(resultNumber); | |||
|
|
|||
| getBackwardSlice(result, &usedOperations, options); | |||
| [[maybe_unused]] LogicalResult ret = | |||
There was a problem hiding this comment.
nit: llvm had a discussion on using maybe_unsuded vs. casting to void and decided on sticking to the latter: https://discourse.llvm.org/t/maybe-unused-vs-attribute-unused-vs-void-var-for-assert-variables/64212
There was a problem hiding this comment.
Thanks, I did not know this! I don't really follow why the conclusion is sticking to the latter. It seems that there is not enough data to say which option wins? I don't have a preference, and I'm okay with both. The reason that I use maybe_unused is just because it looks more modern and descriptive. It looks friendly to people who don't use c++ as their daily programming language, IMO.
Carrying revert:
Cherry-pick:
The revision also fixes torch-mlir for getBackwardSlice changes: iree-org/torch-mlir@05a9860
The changes in IREE are for llvm/llvm-project@6a8dde0
Closes #20928