[all-commits] [llvm/llvm-project] 92e904: [flang][hlfir] Ramp-up support of implicit interfa...

[jeanPerier via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 92e904b9ce2d3319bccf56f05179ee5b5a424f0a
      https://github.com/llvm/llvm-project/commit/92e904b9ce2d3319bccf56f05179ee5b5a424f0a
  Author: Jean Perier <jperier at nvidia.com>
  Date:   2023-02-10 (Fri, 10 Feb 2023)

  Changed paths:
    M flang/include/flang/Optimizer/Dialect/FIROps.td
    M flang/lib/Lower/CallInterface.cpp
    M flang/lib/Lower/ConvertCall.cpp
    M flang/lib/Optimizer/Dialect/FIROps.cpp
    A flang/test/Lower/HLFIR/implicit-call-mismatch.f90

  Log Message:
  -----------
  [flang][hlfir] Ramp-up support of implicit interface mismatches

There is a lot of Fortran code that takes advantage of F77 implicit
interface to pass arguments with a different type than those from
the subprogram definition (which is well defined if the storage
and passing convention are the same or compatible).

When the definition and calls are in different files, there is nothing
special to do: the actual arguments are already used to compute the
call interface.

The trouble for lowering comes when the definition is in the same
compilation unit (Semantics raises warning). Then, lowering will
be provided with the interface from the definition to prepare the
argument, and this leads to many ad-hoc handling (see
builder.convertWithSemantics) in the current lowering to cope
with the dummy/actual mismatches on a case by case basis. The
current lowering to FIR is not even complete for all mismatch cases that
can be found in the wild (see https://github.com/llvm/llvm-project/issues/60550),
it is crashing or hitting asserts for many of the added tests.

For HLFIR, instead of coping on a case by case basis, the call
interface will be recomputed according to the actual arguments when
calling an external procedure that can be called with an explicit
interface.

One extra case still has to be handled manually because it may happen
in calls with explicit interfaces: passing a character procedure
designator to a non character procedure dummy (and vice-versa) is widely
accepted even with explicit interfaces (and flang semantic accepts it).
Yet, this "mismatch" cannot be dealt with a simple fir.convert because
character dummy procedure are passed with a different passing
convention: an extra argument is hoisted for the result length (in FIR,
there is no extra argument yet, but the MLIR func argument is a
tuple<fir.boxproc, len>).

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