[llvm-dev] RFC for f18+runtimes in LLVM

[David Greene via llvm-dev]

Steve, thanks for your thoughtful reply!

Stephen Scalpone via llvm-dev <llvm-dev at lists.llvm.org> writes:

> The advantage of using clang's ASTs for Fortran would be a common
> mechanism for dealing with ASTs.  It doesn't buy an implementation of
> say, clang-tidy, for Fortran.  Either Fortran and C ASTs structs would
> overlay, perhaps creating some confusion because the semantics of
> Fortran and C/C++ are different, or else the Fortran ASTs would extent
> the set of ASTs, again creating some confusion for developer's who
> wouldn't necessarily have a clear idea which structs belonged to which
> language and what, if any, subtle differences in semantics are implied
> by the origin language.

I'm certainly out of my domain here so I'll let Petr and others with
experience drive this discussion.  I understand that simply extending
clang's AST won't magically get tooling working, but it seems to me it
would be a good foundation.

I was imagining that semantic differences would either result in
different AST node types for C/C++ and Fortran where necessary, or
annotations/attributes on existing AST node types.  Those may or may not
result in LLVM IR annotations/intrinsics/etc. (thinking in particular of
the array representation issue mentioned below).

> That said, we've engaged with a handful of Fortran tool authors to
> discuss how f18 can help them with their work.  The feedback has been
> positive -- keep doing what you're doing -- but with one exception I
> don't think any of these developers have engaged with the code yet.

It's good to hear tool developers are engaged!  Are any of them involed
with clang tooling as well?  If so it would be great to get their
insight.

> Yes, we have three reviews in the queue for changes that extend llvm
> debug metadata to support Fortran constructs in DWARF.  The feedback
> requested that one of the changes be implemented differently, which we
> have yet to budget time to reimplement.  The other feedback was for us
> to think harder about mapping Fortran to existing C constructs; our
> experience says this approach won't work because, for example, Fortran
> has much richer array representation than C (negative bounds, dynamic
> bounds, bounds that are associated with variables & not encapsulated
> are part of the array structure). We also want to stay compatible with
> the existing Fortran aware debuggers that expect a certain shape of
> DWARF.  This issue is on use to explain ourselves more clearly.

Understood.

> Sorry it feels that way to you.  Most of our design communication
> happens via github; if you are watching the project you'll see when
> new documents and new code is posted.  As far as I know, anyone can
> participate in a code review; if that is not the case please let me
> know & I'll do what I can to open it up.
>
> Most of what we are working on has been in flight for a long time.
> Two of the longest running tasks -- type declarations and symbols
> resolution and expression analysis, semantics, and folding -- have
> been documented for a long time & have seen many commits as the
> implementation progresses.  In the last month, the control flow graph
> documentation and header files have been open for comments in a pull
> request.  We did get questions and comments (via email) from a few
> people.

I think the main issue is that the LLVM community doesn't really operate
that way.  Design discussion happens on mailing lists.  There's been
some discussion about moving to GitHub PRs but even if a decision is
made to do so, the earliest it could happen is late this fall (1 year
after the monorepo publication).  Even then, I expect higher-level
design work will still happen on the mailing lists.

So when I see "flang-dev" as a mailing list, I expect discussion about,
well, flang development.  :)

I'm hopeful that this RFC will spur some discussion about the current
design.  In the meantime, I'll see if I can subscribe to the GitHub
repository and get notifications.

> Perhaps is my mistake to judge interest in f18 by traffic on github
> and the flang-dev mailing list.  

I think there is a lot of interest!

> I'm happy to host one time or recurring call to discuss f18.  One of
> the action items from last July's introductory call was to schedule
> another call to discuss how arrays would be represented in the CFG and
> in llvm IR; there was lively discussion of various options during the
> July call.

That very discussion came to my mind too.  It's one of the most critical
design questions.

                            -David