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.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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)?
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.