[PATCH] D74401: [MLIR] Add std.atomic_rmw op
Frank Laub via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Feb 11 15:44:23 PST 2020
flaub marked 3 inline comments as not done.
flaub added inline comments.
================
Comment at: mlir/lib/Conversion/StandardToLLVM/ConvertStandardToLLVM.cpp:2518
+template <typename OpType>
+Optional<SimpleAtomicMatch> matchAtomicBinaryOp(AtomicRMWOp atomicOp, OpType op,
+ LLVM::AtomicBinOp binOp) {
----------------
rriddle wrote:
> static functions should be in the global namespace and marked as `static`. Only classes should be placed within anonymous namespaces.
I'm OK with this, but I'm unfamiliar with this convention. What's the purpose behind having functions being `static` instead of being in the anonymous namespace? I was always under the impression that the two were functionally equivalent and that the more 'C++' way was to use anonymous namespaces.
Also, should I close out the namespace here and then add the static functions and then re-open the anonymous namespace? Or would it make sense to move these up above?
================
Comment at: mlir/lib/Dialect/StandardOps/Ops.cpp:3019
+ Type elementType = parentOp.getMemRefType().getElementType();
+ if (elementType != op.result().getType()) {
+ return op.emitOpError() << "needs to have type " << elementType;
----------------
rriddle wrote:
> Remove trivial braces.
>
> I would have expected that this could be covered by ODS constraints.
Did you have a specific trait in mind? I'm comparing the parent's element type to the op's operand type. I didn't see anything in `OpBase.td` at first glance.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D74401/new/
https://reviews.llvm.org/D74401
More information about the llvm-commits
mailing list