Add a HLFIR operation for the MATMUL transformational intrinsic,
according to the design set out in flang/doc/HighLevelFIR.md
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Kudos. You found a pattern. At the top right, you will find Edit Related Revisions ....
LGTM
flang/lib/Optimizer/HLFIR/IR/HLFIROps.cpp | ||
---|---|---|
575–578 | I wonder if there may ever be trouble if one of the input type extent is unknown and the output is a compile time constant or vice-versa. |
flang/lib/Optimizer/HLFIR/IR/HLFIROps.cpp | ||
---|---|---|
575–578 | Thanks for pointing this out, I had overlook this. It turns out that lowering already handles this: adding and removing constant extents: subroutine mul1(lhs, rhs, res) real lhs(2, 2), rhs(2, 2), res(:,:) res = MATMUL(lhs, rhs) ! becomes hlfir.matmul [...] : (!fir.ref<!fir.array<2x2xf32>>, !fir.ref<!fir.array<2x2xf32>>) -> !hlfir.expr<2x2xf32> end subroutine subroutine mul2(lhs, rhs, res) real lhs(:,:), rhs(:,:), res(2,2) res = MATMUL(lhs, rhs) ! becomes hlfir.matmul [...] : (!fir.ref<!fir.array<?x?xf32>>, !fir.ref<!fir.array<?x?xf32>>) -> !hlfir.expr<?x?xf32> end subroutine |
flang/lib/Optimizer/HLFIR/IR/HLFIROps.cpp | ||
---|---|---|
575–578 | Thanks for testing. LGTM. |
I wonder if there may ever be trouble if one of the input type extent is unknown and the output is a compile time constant or vice-versa.
I think it is rather unlikely that lowering gets different type extents here, but I wonder if this could happen after some rewrites/operand propagation.
I say let's keep it simple and strict as you did here, but let's be aware this may have to be relaxed.