[all-commits] [llvm/llvm-project] 2d9b4a: [flang][NFC] share Constant<SomeDerived> lowering

[jeanPerier via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 2d9b4a50cae8d18516a61977768a48d1f92ac33c
      https://github.com/llvm/llvm-project/commit/2d9b4a50cae8d18516a61977768a48d1f92ac33c
  Author: Jean Perier <jperier at nvidia.com>
  Date:   2023-01-05 (Thu, 05 Jan 2023)

  Changed paths:
    M flang/include/flang/Lower/ConvertConstant.h
    M flang/include/flang/Lower/ConvertType.h
    M flang/include/flang/Lower/Mangler.h
    M flang/lib/Lower/ConvertConstant.cpp
    M flang/lib/Lower/ConvertExpr.cpp
    M flang/lib/Lower/ConvertExprToHLFIR.cpp
    M flang/lib/Lower/ConvertType.cpp
    M flang/lib/Lower/ConvertVariable.cpp
    M flang/lib/Lower/Mangler.cpp
    A flang/test/Lower/HLFIR/constant-derived.f90
    A flang/test/Lower/constant-literal-mangling.f90

  Log Message:
  -----------
  [flang][NFC] share Constant<SomeDerived> lowering

A previous patch (https://reviews.llvm.org/D136955) already refactored
intrinsic constant lowering to place in its own file and allow using it from
both the current lowering and the new lowering to HLFIR.

This patch does the same for derived types. The core function
"genStructComponentInInitializer" is moved from ConvertExpr.cpp and
renamed "genInlinedStructureCtorLitImpl" into ConvertConstant.cpp
without significant logic change.

Then, genScalarLit, genArrayLit (and genInlinedArrayLit/genOutlinedArrayLit)
are updated to support derived types.

The core aspect of derived type constant lowering that differs between
the current lowering and the HLFIR update is the way
addresses/initial target descriptors are built when part of a derived
type constant. This part happens in ConvertVariable.cpp (since the
address of a variable is taken in an initializer and is left TODO).

The mangling of derived type global literal constant is fixed: it did not embed
the derived type name and could cause "conflicts" between unrelated
derived types containing the same data. However, the hash remains
unstable between two compilation of the same file. This is not a
correctness issue and would require a lot of work to hash the derived
type constant data without hashing some irrelevant (but not out of bound)
data in the compile time data structure that holds derived type
constants (Constant<SomeDerived>). This may have to be revisited later.

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