This is an archive of the discontinued LLVM Phabricator instance.

[MLIR] NFC. Clean up logic of hasSingleEffect
ClosedPublic

Authored by bondhugula on Jul 10 2022, 12:13 AM.

Details

Summary

Clean up conditional logic of hasSingleEffect. NFC.

Diff Detail

Event Timeline

bondhugula created this revision.Jul 10 2022, 12:13 AM
bondhugula requested review of this revision.Jul 10 2022, 12:13 AM
rriddle accepted this revision.Jul 11 2022, 3:18 PM
rriddle added inline comments.
mlir/lib/Interfaces/SideEffectInterfaces.cpp
99–110

If we check early for effects.empty() and return false, do we even need to track hasSingleEffectOnVal through the loop?

This revision is now accepted and ready to land.Jul 11 2022, 3:18 PM
bondhugula marked an inline comment as done.Jul 12 2022, 5:54 PM
bondhugula added inline comments.
mlir/lib/Interfaces/SideEffectInterfaces.cpp
99–110

We would still need to --- since you could have other effects that are not on value. This method needs to check if EffectTy is the only effect that this op has *on value*. In the logic you suggested, you'd return false even whenever there is an effect on a different value.

If the desired semantics of the method had been to only restrict effects to only this value, then the above logic would implement it compactly. But that's not what is desired here. For eg., a common scenario is check whether an operation only has a "read" memory effect on a specific memref value which happens to be one or more of its operands. We aren't concerned about what other effects the op has on other value operands.

bondhugula marked an inline comment as done.Jul 14 2022, 10:54 PM
This revision was automatically updated to reflect the committed changes.