[all-commits] [llvm/llvm-project] 9fc79a: [flang] Move main variables static promotion from ...

[jeanPerier via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 9fc79ae628d38559803c63f61fc6a8310b909632
      https://github.com/llvm/llvm-project/commit/9fc79ae628d38559803c63f61fc6a8310b909632
  Author: Jean Perier <jperier at nvidia.com>
  Date:   2022-09-28 (Wed, 28 Sep 2022)

  Changed paths:
    M flang/include/flang/Common/Fortran-features.h
    M flang/lib/Evaluate/tools.cpp
    M flang/lib/Lower/PFTBuilder.cpp
    M flang/test/Lower/OpenMP/atomic-read.f90
    M flang/test/Lower/array-character.f90
    M flang/test/Lower/array-expression-slice-1.f90
    M flang/test/Lower/associate-construct.f90
    M flang/test/Lower/io-write.f90
    M flang/test/Lower/namelist.f90

  Log Message:
  -----------
  [flang] Move main variables static promotion from lowering into IsSaved

Currently, lowering is promoting main program array and character
variables that are not saved into static memory.

This causes issues with equivalence initial value images because
semantics is relying on IsSaved to build the initial value of variables
in static memory. It seems more robust to have IsSaved be the place
deciding if a variable needs to be in static memory (except for common
block members).

Move the logic to decide if a main program variable must be in static
memory into evaluate::IsSaved and add two options to semantics to
replace the llvm options that were used in lowering:
 - SaveMainProgram (off by default): save all main program variables.
 - SaveBigMainProgramVariables (on by default): save all main program
   variables that are bigger than 32 bytes.

The first options is required to run a few old programs that expect all
main program variables to be in bss (and therefore zero initialized).

The second option is added to allow performance testing: placing big
arrays in static memory seems a sane default to avoid blowing up the
stack with old programs that define big local arrays in the main
program, but since it is easier to prove that an alloca does not
escape/is not modified by calls, keeping big arrays on the stack could
yield improvements.

The logic of SaveBigMainProgramVariables is slightly changed compared to what
it was doing in lowering. The old code was placing all arrays and all
explicit length characters in static memory.
The new code is placing everything bigger than 32 bytes in static
memory. This has the advantages of being a simpler logic, and covering
the cases of scalar derived type with big array components or many
components. Small strings and arrays are now left on the stack (after
all, a character(1) can fit in register).

Note: I think it could have been nicer to add a single "integer" option
to set a threshold to place main program variables in static memory so
that this can be fine tuned by the drivers (SaveMainProgram would be
implemented by setting it to zero). But the language feature options are
not meant to carry integer options. Extending it for this seems an
overkill precedent, and placing it in SemanticsContext is weird (it is
a too low level option to be a bare member of SemanticsContext in my
opinion). So I just rolled my own dices and picked 32 for the sake of
simplicity.

Differential Revision: https://reviews.llvm.org/D134735