[all-commits] [llvm/llvm-project] 698616: [flang] Submodules

[vdonaldson via All-commits]

  Branch: refs/heads/vkd1
  Home:   https://github.com/llvm/llvm-project
  Commit: 6986167ea3116fce7281a6ce1c1be88ef9b0be27
      https://github.com/llvm/llvm-project/commit/6986167ea3116fce7281a6ce1c1be88ef9b0be27
  Author: V Donaldson <vdonaldson at nvidia.com>
  Date:   2022-12-05 (Mon, 05 Dec 2022)

  Changed paths:
    M flang/include/flang/Lower/ConvertVariable.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 a parent module or an intermediate ancestor 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 a module scope that, while guaranteed to be
present in a .mod file, is not guaranteed to be in the PFT. This difference
is accommodated by tying all scope processing to a front end scope, independent
of the PFT. 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 are also some
incidental bug fixes, such as for variables in equivalence groups used in
namelist groups, which have a loose association with scope processing code.