[PATCH] D99892: [flang] Improve constant folding for type parameter inquiries
Peter Klausler via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Apr 5 13:35:42 PDT 2021
klausler added a comment.
In D99892#2669498 <https://reviews.llvm.org/D99892#2669498>, @PeteSteinfeld wrote:
> Yes, the value of the type parameter is derived from the associated object at the time that the object is instantiated. I believe that the current code is folding the value of the type parameter from the instantiated value. Here's a modified version of your example that illustrates that:
>
> subroutine foo(n)
> type :: t(len)
> integer, len :: len
> end type t
>
> type(t(n)) :: x1
> real(x1%len) :: r1 ! Error since the KIND of r1 isn't constant
> type(t(4)) :: x2
> real(x2%len) :: r2
>
> block
> real(x2%len) :: r3 ! OK, the KIND of r3 is x2%len, which is folded to 4
> end block
> n = 99
> block
> real(x2%len) :: r4 ! Still OK, because the x2%len gets folded to 4
> end block
> end
You're using non-constant expressions to define the LEN type parameter and then catching the error in the outer context, which requires a constant expression. But what about cases where a non-constant expression is used to define a LEN type parameter that is referenced in a context that does not require a constant expression? If the type parameter inquiry is replaced with the actual parameter expression, we'll produce bad results.
subroutine foo(n)
type :: t(len)
integer, len :: len
end type
type(t(n)) :: x
print *, x%len
n = n + 1
print *, x%len ! <--- must not be changed due to modification to 'n'
end subroutine
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D99892/new/
https://reviews.llvm.org/D99892
More information about the llvm-commits
mailing list