This is an archive of the discontinued LLVM Phabricator instance.

[mlir][Conversion] Store const type converter in ConversionPattern
ClosedPublic

Authored by springerm on Aug 10 2023, 4:45 AM.

Details

Summary

ConversionPatterns do not (and should not) modify the type converter that they are using.

  • Make ConversionPattern::typeConverter const.
  • Make member functions of the LLVMTypeConverter const.
  • Conversion patterns take a const type converter.
  • Various helper functions (that are called from patterns) now also take a const type converter.

Depends On: D157611

Diff Detail

Event Timeline

springerm created this revision.Aug 10 2023, 4:45 AM
Herald added a reviewer: aartbik. · View Herald Transcript
Herald added a reviewer: ftynse. · View Herald Transcript
Herald added a reviewer: dcaballe. · View Herald Transcript
Herald added a reviewer: kuhar. · View Herald Transcript
Herald added a reviewer: kuhar. · View Herald Transcript
Herald added a project: Restricted Project. · View Herald Transcript
springerm requested review of this revision.Aug 10 2023, 4:45 AM
nicolasvasilache accepted this revision.Aug 10 2023, 4:56 AM

Great, thanks for untangling this, I had a similar thing in flight but did not get all the spots yet so happy to use this!

This revision is now accepted and ready to land.Aug 10 2023, 4:56 AM
springerm edited the summary of this revision. (Show Details)Aug 10 2023, 6:28 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 10 2023, 6:30 AM

What is the motivation for this change beyond cleaning up the code? IIRC the mlir policy discourages const in the general case: https://mlir.llvm.org/getting_started/DeveloperGuide/#style-guide, so I'm wondering if you plan some future API changes stacked on top of this one.

Do we need this because matchAndRewrite is marked as const? As an alternative could we remove the const qualifiers in RewritePattern, or has the ship already sailed there?

What is the motivation for this change beyond cleaning up the code? IIRC the mlir policy discourages const in the general case: https://mlir.llvm.org/getting_started/DeveloperGuide/#style-guide, so I'm wondering if you plan some future API changes stacked on top of this one.

Do we need this because matchAndRewrite is marked as const? As an alternative could we remove the const qualifiers in RewritePattern, or has the ship already sailed there?

The style guide reads to me like this only applies to IR constructs. The linked rationale doc even clarifies further and seems to suggest that it only applies to operations, blocks and regions. This has previously come up here: https://discourse.llvm.org/t/clarifying-usage-of-const/4986/2. So I don't think this patch is in conflict with that policy.

kuhar added a subscriber: Mogball.Aug 10 2023, 12:05 PM

What is the motivation for this change beyond cleaning up the code? IIRC the mlir policy discourages const in the general case: https://mlir.llvm.org/getting_started/DeveloperGuide/#style-guide, so I'm wondering if you plan some future API changes stacked on top of this one.

Do we need this because matchAndRewrite is marked as const? As an alternative could we remove the const qualifiers in RewritePattern, or has the ship already sailed there?

The style guide reads to me like this only applies to IR constructs. The linked rationale doc even clarifies further and seems to suggest that it only applies to operations, blocks and regions. This has previously come up here: https://discourse.llvm.org/t/clarifying-usage-of-const/4986/2. So I don't think this patch is in conflict with that policy.

Ah, I vaguely recall @Mogball arguing the opposite interpretation when it came to local variables etc. If that's the case, I guess we fallback to general rules of idiomatic C++ in the rest of the project. Separately from this revision, we may expand on the constness policy on the website because this keeps coming up.

What is the motivation for this change beyond cleaning up the code?

Yes, this is a cleanup. And it hardens the API to prevent users from changing the type converter while a dialect conversion is in progress. It is not related to matchAndRewrite (or the fact that it is const).
Discussion: https://discourse.llvm.org/t/rfc-almost-all-uses-of-typeconverter-should-be-const/72689

kuhar accepted this revision.Aug 10 2023, 12:15 PM

What is the motivation for this change beyond cleaning up the code?

Yes, this is a cleanup. And it hardens the API to prevent users from changing the type converter while a dialect conversion is in progress. It is not related to matchAndRewrite (or the fact that it is const).
Discussion: https://discourse.llvm.org/t/rfc-almost-all-uses-of-typeconverter-should-be-const/72689

SGTM. Could you add the link to the RFC to the commit description?

Apologies for missing the RFC, but I am a small -1 on this direction. The rationale I have for allowing mutability of a type converter instance is caching expensive type conversions in a hashmap inside the type converter. It's specific to my use case and I can always add a separate path, however.

On the general const policy of the codebase, the emphasis is definitely on the core language constructs but the overall coding style of MLIR is not go crazy and mark things as const unless there is an invariant to enforce. It seems with TypeConverter the invariant is useful to enforce so this makes sense to me.

The rationale I have for allowing mutability of a type converter instance is caching expensive type conversions in a hashmap inside the type converter. It's specific to my use case and I can always add a separate path, however.

I made sure that we can still cache type conversions: D157597

mehdi_amini accepted this revision.Aug 11 2023, 1:03 AM

The rationale I have for allowing mutability of a type converter instance is caching expensive type conversions in a hashmap inside the type converter. It's specific to my use case and I can always add a separate path, however.

I made sure that we can still cache type conversions: D157597

Seems like everyone is happy with this?
If so, thanks for the cleanup: mutable state is harder to reason through!