This is an archive of the discontinued LLVM Phabricator instance.

[mlir] Argument and result attribute handling during inlining.
ClosedPublic

Authored by gysit on Mar 8 2023, 5:28 AM.

Details

Summary

The revision adds the handleArgument and handleResult handlers that
allow users of the inlining interface to implement argument and result
conversions that take argument and result attributes into account. The
motivating use cases for this revision are taken from the LLVM dialect
inliner, which has to copy arguments that are marked as byval and that
also has to consider zeroext / signext when converting integers.

All type conversions are currently handled by the
materializeCallConversion hook. It runs before isLegalToInline and
supports only the introduction of a single cast operation since it may
have to rollback. The new handlers run shortly before and after
inlining and cannot fail. As a result, they can introduce more complex
ir such as copying a struct argument. At the moment, the new hooks
cannot be used to perform type conversions since all type conversions
have to be done using the materializeCallConversion. A follow up
revision will either relax this constraint or drop
materializeCallConversion in favor of the new and more flexible
handlers.

The revision also extends the CallableOpInterface to provide access
to the argument and result attributes if available.

Diff Detail

Event Timeline

gysit created this revision.Mar 8 2023, 5:28 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 8 2023, 5:28 AM
gysit requested review of this revision.Mar 8 2023, 5:28 AM

Dropped some comments.

mlir/lib/Transforms/Utils/InliningUtils.cpp
178

A comment suggest that the dictionary attributes passed to the handleArgument are non-null. Thus, I would prefer to use cast here, as it will assert when this cast fails and not silently return null and then violate the pre-condition of handleArgument.

207

As above.

gysit updated this revision to Diff 504439.Mar 12 2023, 8:00 AM

Address review comments and rebase.

This revision is now accepted and ready to land.Mar 14 2023, 12:59 AM
mehdi_amini requested changes to this revision.Mar 14 2023, 5:20 AM

Please get reviews from @rriddle here.

This revision now requires changes to proceed.Mar 14 2023, 5:20 AM
rriddle accepted this revision.Mar 15 2023, 12:20 AM

Patch looks reasonable to me.

mlir/include/mlir/Interfaces/CallInterfaces.td
94–108

What's the benefit of a default implementation here? Why not force users to provide this? (I assume most will)

mlir/lib/Transforms/Utils/InliningUtils.cpp
110

What's the tradeoff of having this anchored on the call vs the callable?

168–169

I'd hoist these checks out, they make a bit more sense in the caller.

198–199

Same here

gysit updated this revision to Diff 505822.Mar 16 2023, 8:40 AM
gysit marked 3 inline comments as done.

Address review comments.

gysit added a comment.Mar 16 2023, 8:42 AM

Thanks for the review!

mlir/include/mlir/Interfaces/CallInterfaces.td
94–108

Yes makes sense!

mlir/lib/Transforms/Utils/InliningUtils.cpp
110

It is not completely clear to me which one makes more sense here. I used the call since the existing type conversion hook did so. Another argument in-favor of using the call is that the newly created IR is introduced in-place of the call operation. On the other hand, the callable carries the argument and result attributes. I think the later is a pretty strong argument for anchoring on the callable. I updated the revision accordingly. Let me know if you think it is not an improvement.

gysit updated this revision to Diff 505981.Mar 16 2023, 8:51 PM

Fix toy dialect.

This revision is now accepted and ready to land.Mar 20 2023, 1:05 AM
This revision now requires review to proceed.Mar 20 2023, 1:05 AM

Still, LGTM (feel free to land).

mlir/lib/Transforms/Utils/InliningUtils.cpp
110

LGTM. I was thinking the callable as well given it is the one that should have an indication of what the attributes are, though if we really need a different handling that can be added as necessary.

Still, LGTM (feel free to land).

I was waiting due to the blocking review of @jpienaar. Is it ok to land nevertheless?

Still, LGTM (feel free to land).

I was waiting due to the blocking review of @jpienaar. Is it ok to land nevertheless?

Yeah, it should be fine in this case.

gysit updated this revision to Diff 507255.Mar 22 2023, 12:26 AM

Rebase and implement new methods on a newly added callable op.

This revision was not accepted when it landed; it landed in state Needs Review.Mar 22 2023, 1:08 AM
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.