This is an archive of the discontinued LLVM Phabricator instance.

[flang] derived-type finalization
ClosedPublic

Authored by clementval on Jan 27 2023, 4:56 AM.

Details

Summary

This patch implements the derived-type finalization for
monomorphic and polymorphic derived-type.

The finalization is done through a call to the Destroy
runtime function so the allocatable component object are also
finalized correctly when needed. It would be possible to finalize
monomorphic derived-type with non finalizable component with a
direct call to their finalize subroutine.

7.5.6.3 point 1: LHS nonallocatable object and LHS allocatable
object finalization. Done with call to Destroy for monomorphic
derived-type and through Assign for polymorphic entities.

7.5.6.3 point 2: Done within the deallocation calls.

7.5.6.3 point 3: A function context is added to the bridge to
attach finalization that need to happen on function/subroutine
exit.

7.5.6.3 point 4: BLOCK construct not yet implemented.

7.5.6.3 point 5/6: Finalization attach to the stmtCtx in a
similar way than 9.7.3.2 point 4.

7.5.6.3 point 7: INTENT(OUT) finalization done with a
call to Destroy runtime function call.

This patch passes 9/10 tests in the proposed test-suite
https://github.com/llvm/llvm-test-suite/pull/13

  • The case with BLOCK construct will be implemented later when BLOCK are implemented upstream.
  • Automatic deallocation is not yet implemented. Finalization triggered by automatic deallocation is then not triggered.

Diff Detail

Event Timeline

clementval created this revision.Jan 27 2023, 4:56 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald Transcript
clementval requested review of this revision.Jan 27 2023, 4:56 AM
jeanPerier accepted this revision.Jan 27 2023, 5:59 AM

Other than my comment about IsSaved and about the assignment case, this looks good to me.

flang/lib/Lower/Bridge.cpp
2806

I won't push you to deal with this now because I think you would have a better time doing this with HLFIR, but I do not think it is OK to destroy the lhs at that point in case the rhs overlaps/is the same as the lhs.
I guess this overlap scenario is even more relevant in the array assignment case (which I do not think this patch is covering since I think the code for array assignment is doing an early exit with genArrayAssignment).

In HLFIR, I think the solution will be to add a finalize optional unit attribute to hlfir::assign operation and to insert the lhs destroy after the rhs temporization if there is any possible aliasing. I am OK with leaving this a TODO in the current lowering for now.

By the way, do you know if it is possible to use assignments that require LHS finalization inside a FORALL ?

flang/lib/Lower/ConvertVariable.cpp
650

I think Saved objects may need to be excluded here. Point 3 sayes: "[...] before it would become undefined due to execution of a RETURN", but saved object do not become undefined with the execution of a RETURN. Also see NOTE 1 in "7.5.6.4" : "A nonpointer, nonallocatable object that has the SAVE attribute is never finalized as a direct consequence of the execution of a RETURN or END statement."

This revision is now accepted and ready to land.Jan 27 2023, 5:59 AM
clementval added inline comments.Jan 27 2023, 6:14 AM
flang/lib/Lower/Bridge.cpp
2806

Good point indeed. I'll add a TODO.

I completely forgot the genArrayAssignment even it was under my radar.

I did not see any restriction regarding FORALL beside that the FINAL subroutine must be PURE.

flang/lib/Lower/ConvertVariable.cpp
650

Good catch. I'll update that.

PeteSteinfeld accepted this revision.Jan 27 2023, 6:31 AM

Aside from the one nit, all builds and tests correctly and looks good.

flang/lib/Lower/ConvertCall.cpp
380–381

I didn't understand this sentence. Did you mean to say "Check of the derived-type is finalizable because it is a monomorphic derived-type."?

clementval marked an inline comment as done.

Add todo + IsSaved

This revision was automatically updated to reflect the committed changes.