commit | dbf782e6997357ba1886face68203e6c1998fb83 | [log] [tgz] |
---|---|---|
author | jeanPerier <jperier@nvidia.com> | Tue Mar 12 10:29:19 2024 +0100 |
committer | Copybara-Service <copybara-worker@google.com> | Tue Mar 12 02:39:32 2024 -0700 |
tree | 4a25729feb541092b07f6b6b38b7fc33350c1f73 | |
parent | 0409ea0310b00f63fd68ed4a858d415922d3c7f6 [diff] |
[flang] lower vector subscripted polymorphic designators (#84778) A mold argument need to be added to the hlfir.element_addr and set in lowering so that when the hlfir.element_addr need to be turned into an hlfir.elemental operation because the designator must be turned into a value, the mold can be set on the hlfir.elemental to later allocate the temporary according the the dynamic type. This situation happens whenever the vector subscripted polymorphic designator does not appear as an assignment left-hand side, or as an IO-input item. I initially thought retrieving the mold would be tricky if the dynamic type of the designator was set by a part-ref of the right of the vector subscripts ("array(vector)%polymorphic_comp"), but this turned out to be impossible because: 1. A derived type component can be polymorphic only if it has the POINTER or ALLOCATABLE attribute (F2023 C708). 2. Vector-subscripted part are ranked and F2023 C919 prohibits any part-ref on the right of the rank part to have the POINTER or ALLOCATABLE attribute. => If a vector subscripted designator is polymorphic, the vector subscripted part is the rightmost part, and the mold is the base of the vector subscripted part. This makes the retrieval of the mold easy in lowering. The mold argument is always set to be the base of the vector subscripted part when lowering the vector subscripted part, and it is removed at the end of the designator lowering if the designator is not polymorphic. This way there is no need to find back the mold from the inside of the hlfir.element_addr body. GitOrigin-RevId: 939f038296e601abd9143955f1b347aee1e99c06
Flang is a ground-up implementation of a Fortran front end written in modern C++. It started off as the f18 project (https://github.com/flang-compiler/f18) with an aim to replace the previous flang project (https://github.com/flang-compiler/flang) and address its various deficiencies. F18 was subsequently accepted into the LLVM project and rechristened as Flang.
Please note that flang is not ready yet for production usage.
Read more about flang in the docs directory. Start with the compiler overview.
To better understand Fortran as a language and the specific grammar accepted by flang, read Fortran For C Programmers and flang's specifications of the Fortran grammar and the OpenMP grammar.
Treatment of language extensions is covered in this document.
To understand the compilers handling of intrinsics, see the discussion of intrinsics.
To understand how a flang program communicates with libraries at runtime, see the discussion of runtime descriptors.
If you're interested in contributing to the compiler, read the style guide and also review how flang uses modern C++ features.
If you are interested in writing new documentation, follow LLVM's Markdown style guide.
Consult the Getting Started with Flang for information on building and running flang.