[all-commits] [llvm/llvm-project] 518e6f: [flang] Submodules

[vdonaldson via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 518e6f12f37cc47be99c6d218bf07c0191c66de2
      https://github.com/llvm/llvm-project/commit/518e6f12f37cc47be99c6d218bf07c0191c66de2
  Author: V Donaldson <vdonaldson at nvidia.com>
  Date:   2022-12-13 (Tue, 13 Dec 2022)

  Changed paths:
    M flang/include/flang/Lower/ConvertVariable.h
    M flang/include/flang/Lower/Mangler.h
    M flang/include/flang/Lower/PFTBuilder.h
    M flang/lib/Lower/Bridge.cpp
    M flang/lib/Lower/ConvertVariable.cpp
    M flang/lib/Lower/IO.cpp
    M flang/lib/Lower/Mangler.cpp
    M flang/lib/Lower/PFTBuilder.cpp
    M flang/test/Lower/pre-fir-tree01.f90
    M flang/test/Lower/pre-fir-tree02.f90
    M flang/test/Lower/pre-fir-tree06.f90
    M flang/test/Lower/pre-fir-tree07.f90
    A flang/test/Lower/submodule.f90

  Log Message:
  -----------
  [flang] Submodules

A submodule is a program unit that may contain the implementions of procedures
declared in an ancestor module or submodule.

Processing for the equivalence groups and variables declared in a submodule
scope is similar to existing processing for the equivalence groups and
variables in module and procedure scopes. However, module and procedure scopes
are tied directly to code in the Pre-FIR Tree (PFT), whereas processing for a
submodule must have access to an ancestor module scope that is guaranteed
to be present in a .mod file, but is not guaranteed to be in the PFT. This
difference is accommodated by tying processing directly to a front end scope.
Function scopes that can be processed on the fly are done that way; the
resulting variable information is never stored. Module and submodule scopes
whose symbol information may be needed during lowering of any number of module
procedures are instead cached on first use, and reused as needed.

These changes are a direct extension of current code. All module and submodule
variables in scope are processed, whether referenced or not. A possible
alternative would be to instead process symbols only when first used. While
this could ultimately be beneficial, such an approach must account for the
presence of equivalence groups. That information is not currently available
for on-the-fly variable processing.

Some additional changes are needed to include submodules in places where
modules must be considered, and to include separate module procedures in
places where other subprogram variants are considered. There is also a fix
for a bug involving the use of variables in an equivalence group in a
namelist group, which also involves scope processing code.