ARM shortly adding a Flang developer

[Geraint North]

Hi all,

As part of the Mont-Blanc 3 project, a new software developer will join my team later this year to work full-time on Flang.  Do we have an expectation of what the development priorities will be in a couple of months, and therefore what might be the most useful activities for him to get started with?  We're obviously motivated to support and defend ARM targets, but the overall remit is to do whatever it takes to bring a Fortran front-end to LLVM, so we won't be limited to ARM-specific work.

Thanks,

Geraint.

---

Geraint North

HPC Architect, ARM Manchester Design Centre

ARM Limited

[Hal Finkel]

Hi Geraint,

That's great news!

[I'll write a more-detailed message discussing some work-items and goals later today.]

-Hal

----- Original Message -----
> From: "Geraint North" <ger...@geraintnorth.com>
> To: "flang-dev" <flan...@googlegroups.com>
> Sent: Monday, October 5, 2015 8:39:25 AM
> Subject: [flang-dev] ARM shortly adding a Flang developer
>
>
> Hi all,
>
>
> As part of the Mont-Blanc 3 project, a new software developer will
> join my team later this year to work full-time on Flang. Do we have
> an expectation of what the development priorities will be in a
> couple of months, and therefore what might be the most useful
> activities for him to get started with? We're obviously motivated to
> support and defend ARM targets, but the overall remit is to do
> whatever it takes to bring a Fortran front-end to LLVM, so we won't
> be limited to ARM-specific work.
>
>
> Thanks,
> Geraint.
>
>
>
>
>
>

> Geraint North
>
> HPC Architect, ARM Manchester Design Centre
>
> ARM Limited
>
>
>
>
>
>
>

> --
> You received this message because you are subscribed to the Google
> Groups "flang-dev" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to flang-dev+...@googlegroups.com .
> To post to this group, send email to flan...@googlegroups.com .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/flang-dev/c9e491b8-26e6-4178-b7df-34d4a12460d5%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout .
>

--
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

[Hal Finkel]

Hi Geraint,

Obviously this is a bit delayed, and I apologize.

For general context: First, we have a repository here (https://github.com/llvm-flang/flang) with the current source. It has been rebased fairly recently, and has received some work recently by members of the community. Second, in parallel, work on Flang has been done by Craig and Ben at Codethink Labs (cc'd). They have a repository https://github.com/CodethinkLabs/flang -- and I believe their repository has received more feature-development work. We need some better coordination here (but that's the subject of a different thread, which I've just pinged).

There are two major areas in which work is needed now, and will help regardless of how we move forward in the long term.

First, in order to be able to use Flang as part of a toolchain with existing build tools, it needs a better driver. The best path forward seems to be to add the necessary support into Clang, and let Clang's driver serve as Flang's as well. Clang, as it turns out, already has some functionality to serve as a Fortran driver (it can call gfortran for Fortran), and extending it to usefully call Flang should not be too difficult. Regardless of the exact path taken, Clang's driver has a lot of logic for finding system libraries, calling systems assemblers, linkers and other tools, etc. for many different platforms. Flang needs essentially all of this logic verbatim, and so we need some way of taking advantage of it without duplication.

Second, Flang currently uses a hard-coded x86_64 set of ABI choices, and is unlikely to work optimally on other platforms (at least not in an ABI-compatible way with other Fortan compilers). This needs work. Here again, we have a choice, because a lot of the necessary logic already exists in Clang. So we can either refactor that logic so that Flang can use it, or we can duplicate that which is necessary. My preference would be to refactor Clang's logic so that it is usable by external projects. This is a generally-useful project, as there are lots of external projects that would like to understand C types, C structure layout, etc. We talked about this briefly in the context of the "llvm-abi" thread on cfe-dev back in June. FWIW, I recommend that you start here, because there is clearly work to do to bring ARM/AArch64 support online, and is also a major issue we'll need to deal with for the life of the project (because if you put 'BIND(C) on a type, then you need to engage all of the C ABI structure-layout logic to get the correct behavior).

Thanks again,

> https://groups.google.com/d/msgid/flang-dev/10748581.748.1444074345205.JavaMail.javamailuser%40localhost.

[Geraint North]

Hi Hal - thanks for the detailed response (and apologies at my end for the late reply!).  Our new developer starts on Monday, so I'll get him started and I'm sure he'll be back here for some more detail before long.  I agree that work on the ABI design would be a good starting point, but from my reading of your note, any actual implementation would probably be gated on the successful refactoring of the key parts of clang so that flang wouldn't have to reinvent them, is that correct?

Thanks,

Geraint.

[Hal Finkel]

Hi Geraint,

Now that the PGI announcement is public, and I had an opportunity to talk to some other LLVM developers and/with some of the PGI developers...

There are two aspects of the ABI that I know about that are potentially-relevant here:

1. Structure layout

2. Function-call value representation coercion

Regarding (1), I had thought that we'd need to do extensive borrowing from Clang to get the target-ABI-specific aspects of structure layout correct (for structures with BIND(C) attached). I discussed this with Chandler and Bob Scollard (PGI), and their feeling is that this is a non-issue. MOst of the non-trivial layout logic in Clang relates to things like bit fields and other things that are not relevant to Fortran. Just using LLVM structure types should be generally sufficient, and messing around with Clang's logic is not worthwhile for any remaining corner cases.

The issues surrounding (2) might be more difficult. This is essentially the logic in Clang's lib/CodeGen/TargetInfo.cpp, and deals with how various types are marshaled through the IR across function-call boundaries. As my colleagues at IBM reminded me, this can be non-trivial, and touches on some very-lightly-documented contracts between the frontends and the backends in order to comply with ABI requirements (on PowerPC, for example, some types are coerced into arrays for correct argument stack layout and register assignment). A lot of this cannot be done strictly at the IR level because it deals with higher-level types (_Complex, for example, which the IR cannot see directly).

Thus, regarding the ABI task, I think the first task is to study the depth of the problem (the amount of code from lib/CodeGen/TargetInfo.cpp that would need to be duplicated) and decide whether it is worth just duplicating the necessary parts of it (with a Fortran/ISO_C_BINDING theme), or refactoring it so that both Flang and Clang can use it.

Thanks again,
Hal

----- Original Message -----
> From: "Geraint North" <ger...@geraintnorth.com>
> To: "flang-dev" <flan...@googlegroups.com>
> Cc: ger...@geraintnorth.com
> Sent: Wednesday, November 11, 2015 5:20:23 AM
> Subject: Re: [flang-dev] ARM shortly adding a Flang developer
>
>

> Hi Hal - thanks for the detailed response (and apologies at my end
> for the late reply!). Our new developer starts on Monday, so I'll
> get him started and I'm sure he'll be back here for some more detail
> before long. I agree that work on the ABI design would be a good
> starting point, but from my reading of your note, any actual
> implementation would probably be gated on the successful refactoring
> of the key parts of clang so that flang wouldn't have to reinvent
> them, is that correct?
>
>
> Thanks,
> Geraint.
>
> On Sunday, October 25, 2015 at 3:19:09 PM UTC, hfinkel wrote:
>
> Hi Geraint,
>
> Obviously this is a bit delayed, and I apologize.
>
> For general context: First, we have a repository here (

> https://github.com/llvm-flang/flang ) with the current source. It

> > https://groups.google.com/d/msgid/flang-dev/10748581.748.1444074345205.JavaMail.javamailuser%40localhost

> > .
> > For more options, visit https://groups.google.com/d/optout .
> >
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "flang-dev" group.
> To unsubscribe from this group and stop receiving emails from it,

> send an email to flang-dev+...@googlegroups.com .
> To post to this group, send email to flan...@googlegroups.com .
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/flang-dev/20e3bbed-a5d1-4dbd-9d68-f9c67e194f66%40googlegroups.com