V Donaldson 1e1f60c605 [flang] Alternate entry points with unused arguments ...

A dummy argument in an entry point of a subprogram with multiple
entry points need not be defined in other entry points. It is only
legal to reference such an argument when calling an entry point that
does have a definition. An entry point without such a definition
needs a local "substitute" definition sufficient to generate code.
It is nonconformant to reference such a definition at runtime.
Most such definitions and associated code will be deleted as dead
code at compile time. However, that is not always possible, as in
the following code. This code is conformant if all calls to entry
point ss set m=3, and all calls to entry point ee set n=3.

subroutine ss(a, b, m, d, k) ! no x, y, n
  integer :: a(m), b(a(m)), m, d(k)
  integer :: x(n), y(x(n)), n
  integer :: k
1 print*, m, k
  print*, a
  print*, b
  print*, d
  if (m == 3) return
entry ee(x, y, n, d, k) ! no a, b, m
  print*, n, k
  print*, x
  print*, y
  print*, d
  if (n /= 3) goto 1
end

  integer :: xx(3), yy(5), zz(3)
  xx = 5
  yy = 7
  zz = 9
  call ss(xx, yy, 3, zz, 3)
  call ss(xx, yy, 3, zz, 3)
end

Lowering currently generates fir::UndefOp's for all unused arguments.
This is usually ok, but cases such as the one here incorrectly access
unused UndefOp arguments for m and n from an entry point that doesn't
have a proper definition.

The problem is addressed by creating a more complete definition of an
unused argument in most cases. This is implemented in large part by
moving the definition of an unused argument from mapDummiesAndResults
to mapSymbolAttributes. The code in mapSymbolAttributes then chooses
one of three code generation options, depending on information
available there.

This patch deals with dummy procedures in alternate entries, and adds
a TODO for procedure pointers (the PFTBuilder is modified to analyze
procedure pointer symbol so that they are not silently ignored, and
instead hits proper TODOs).

BoxAnalyzer is also changed because assumed-sized arrays were wrongfully
categorized as constant shape arrays.  This had no impact, except when
there were unused entry points.

Co-authored-by: jeanPerier <jperier@nvidia.com>

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

2022-05-24 10:56:04 -07:00

89 KiB

Raw Blame History

View Raw