This is an archive of the discontinued LLVM Phabricator instance.

[mlir] LLVM lowering: don't use calling convention in op returns
ClosedPublic

Authored by ftynse on Apr 12 2023, 2:22 AM.

Details

Summary

Conversions to the LLVM dialect have an option to use the "bare pointer"
calling convention that converts memref types differently than the
default convention. It has crept into the conversion of operations that
are not related to calls but do require multiresult-to-struct packing.
Use a similar mechanism for the latter without using the calling
convention.

Diff Detail

Event Timeline

ftynse created this revision.Apr 12 2023, 2:22 AM
Herald added a project: Restricted Project. · View Herald Transcript
ftynse requested review of this revision.Apr 12 2023, 2:22 AM
gysit accepted this revision.Apr 12 2023, 3:17 AM

LGTM, would it be NFC since there are no test modifications needed?

This revision is now accepted and ready to land.Apr 12 2023, 3:17 AM

I don't have a good way to test this. The issue is only exposed if you pass an LLVMTypeConverter configured for the bare-pointer convention into populateArithToLLVMConversionPatterns, which our current passes don't do and probably don't want to do. Any suggestion (short of rolling a test pass that combines patterns)?

gysit added a comment.Apr 12 2023, 4:01 AM

I don't have a good way to test this. The issue is only exposed if you pass an LLVMTypeConverter configured for the bare-pointer convention into populateArithToLLVMConversionPatterns, which our current passes don't do and probably don't want to do. Any suggestion (short of rolling a test pass that combines patterns)?

At least the standard use case is tested but not the corner case you are fixing?

I am surprised the Arith to LLVM lowering can go wrong. Isn't the difference the memref result handling only?

I would also assume a test conversion pass is probably the "easiest" way to test the behavior if you want to add a test. However, it seems like a lot of effort for a quite exotic use case?

Indeed, this is relevant only for memrefs. Specifically, I have a downstream client that fails when lowering arith.select : mermef<42xf32> with bare pointers because it rolls a custom pass mixing multiple patterns.

This revision was landed with ongoing or failed builds.Apr 13 2023, 3:57 AM
This revision was automatically updated to reflect the committed changes.