[all-commits] [llvm/llvm-project] 3ce7e4: [flang] fix fir.array_coor of fir.box with compone...

[jeanPerier via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 3ce7e4b28d6ef8bdaf4ed22bf0337c70ccee8149
      https://github.com/llvm/llvm-project/commit/3ce7e4b28d6ef8bdaf4ed22bf0337c70ccee8149
  Author: Jean Perier <jperier at nvidia.com>
  Date:   2023-04-14 (Fri, 14 Apr 2023)

  Changed paths:
    M flang/lib/Optimizer/CodeGen/CodeGen.cpp
    M flang/test/Fir/array-coor.fir

  Log Message:
  -----------
  [flang] fix fir.array_coor of fir.box with component references

When dealing with "derived_array(j)%component" where derived_array
is not a contiguous array, but for which we know the extent, lowering
generates a fir.array_coor op on a !fir.box<!fir.array<cst x T>> with
a fir.slice containing "j" in the component path.

Codegen first computes "derived_array(j)" address using the byte
strides inside the descriptor, and then computes the offset of "j"
from that address with a second GEP.
The type of the address in that second GEP matters since "j" is passed
in the GEP via an index indicating its component position in the type.

The code was using the LLVM type of "derived_array" instead of
"derived_array(j)".
In general, with fir.box, the extent ("cst" above) is unknown and those
types match. But if the extent of "derived_array" is a compile time
constant, its LLVM type will be [cst x T] instead of T*, and the produced
GEP will compute the address of the nth T instead of the nth component
inside T leading to undefined behaviors.

Fix this by computing the element type for the second GEP.

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