This is an archive of the discontinued LLVM Phabricator instance.

[mlir] Make use of C++17 language features
ClosedPublic

Authored by zero9178 on Aug 6 2022, 5:50 AM.

Details

Summary

Now that C++17 is enabled in LLVM, a lot of the TODOs and patterns to emulate C++17 features can be eliminated.
The steps I have taken were essentially:

git grep C++17
git grep c++17
git grep "initializer_list<int>"

and address given comments and patterns.
Most of the changes boiled down to just using fold expressions rather than initializer_list.

While doing this I also discovered that Clang by default restricts the depth of fold expressions to 256 elements. I specifically hit this with TestDialect in addOperations. I opted to not replace it with fold expressions because of that but instead adding a comment documenting the issue.
If any other functions may be called with more than 256 elements in the future we might have to revert other parts as well.
I don't think this is a common occurence besides the TestDialect however. If need be, this could potentially be fixed via mlir-tblgen in the future.

Diff Detail

Event Timeline

zero9178 created this revision.Aug 6 2022, 5:50 AM
Herald added a reviewer: sjarus. · View Herald Transcript
Herald added a project: Restricted Project. · View Herald Transcript
zero9178 requested review of this revision.Aug 6 2022, 5:50 AM
zero9178 added inline comments.Aug 6 2022, 5:53 AM
mlir/include/mlir/IR/BuiltinAttributes.h
87

I removed this comment because I felt it was not really applicable/an improvement. One place one could use std::disjunction below would be to replace llvm::is_one_of, which felt uneccessary to me, or as a replacement for the || of the two terms, which I felt like is not really an improvement either.

Mogball accepted this revision.Aug 6 2022, 7:27 AM

There are plenty of places that can use structured bindings too (llvm::zip, etc.)

mlir/include/mlir/IR/Dialect.h
215

You can change this with -fbracket-depth I think, but that's not great and I worry about dialects with too many ops

This revision is now accepted and ready to land.Aug 6 2022, 7:27 AM

There are plenty of places that can use structured bindings too (llvm::zip, etc.)

That's true and I have thought about it, but I think this might require a discussion before doing so as structured bindings essentially require the use of auto in places we have previously discouraged them.

mlir/include/mlir/IR/Dialect.h
215

That might be a good solution if we consider just TestDialect on clang having this issue. But since this is used by EVERYONE downstream in a header I'd rather not have to tell everyone "please just add this compiler flag to your build system when using clang".
At least not in this patch.

zero9178 updated this revision to Diff 450534.Aug 6 2022, 8:05 AM

Fix examples/standalone build

In many cases, I'd expect

for (auto [operand, type] : llvm::zip(operands, types)) {
}

to be preferred to

for (auto it = llvm::zip(operands, types)) {
  Value operand = std::get<0>(it);
  Type type = std::get<1>(it);
}
jpienaar added inline comments.Aug 6 2022, 8:50 AM
mlir/include/mlir/IR/Dialect.h
215

Yes as I can think of two larger dialects than Test.

This revision was automatically updated to reflect the committed changes.
mehdi_amini added inline comments.Aug 8 2022, 1:25 AM
mlir/include/mlir/IR/Dialect.h
215

I think we should move away from our current macro based expansion and variadic templates, and generate code with TableGen directly instead.

mlir/lib/Conversion/MemRefToLLVM/MemRefToLLVM.cpp
181

Is inline useful here? I thought this was the default in C++17?

zero9178 added inline comments.Aug 8 2022, 4:17 AM
mlir/lib/Conversion/MemRefToLLVM/MemRefToLLVM.cpp
181

You're right. constexpr implies inline for static member variables.
Fixing in a follow up commit

Really awesome! Thanks for doing this.