Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
The situation is different between a fir.box and an hlfir.expr here. Returning an empty vector from a fir.shape value here will violate what some of the user expect (like getIndexExtents). I think a new operation is needed here to get an extent from a fir.shape instead (or maybe from an hlfir.expr).
The rational is that it must always be possible to get an extent value in lowering (required to generate loop nest, or answer extent inquires). With a fir.box, if this code "fails" because the input is a fir::ShiftOp, the helper tools will generate fir.box_dim on the fir.box. But with an hlfir.expr, there is no way to get a single extent.
Places that would fail:
This will violates getIndexExtents contract: https://github.com/llvm/llvm-project/blob/main/flang/include/flang/Optimizer/Builder/HLFIRTools.h#L306-L310
Example of program that would likely fail to compile properly:
subroutine foo(a, b) real :: a(:, :), b(:, :) interface elemental subroutine elem_sub(x) real, intent(in) :: x end subroutine end interface call elem_sub(matmul(a,b)) end subroutine
This would also still leave the TODO in genExtent: https://github.com/llvm/llvm-project/blob/3ad26060e4bceb2cf9f4959d659cbb29d88344cf/flang/lib/Optimizer/Builder/HLFIRTools.cpp#L523
Likely hit by:
subroutine foo(a, b) real :: a(:, :), b(:, :) print *, size(matmul(a,b), dim=1) end subroutine
Thanks for pointing these out. I added the first example as a testcase here and in https://reviews.llvm.org/D148222
There seems to be something wrong with the patch application. Other than that, this looks great, thanks for dealing with the issue.