llvm dev - Jan 2020 - Flang landing in the monorepo - next Monday!

Hal, Eric, Johannes, David and Peter,

I lead the development of OpenMP for AMD GPUs and work with others at AMD
who support OpenMP on AMD CPUs. On behalf of our development teams, we
greatly appreciate your efforts to move the development of flang into a
subproject in the llvm-project repository and to integrate this development
effort into the overall LLVM development community.

Like most commercial companies, we have certain procedures (some legal) to
participate in open source projects.  Since AMD has already engaged in LLVM
development, adding flang as an LLVM subproject makes it much easier to
participate in the development of flang.    I look forward to my team
getting more involved in the development of flang now that it is part of
LLVM.

I would respectfully disagree with "There's nothing llvm about
it".  Flang
uses the clang offloading architecture used by cuda, hip, and
openmp-target.  And the runtime will use both libomp and libomptarget
runtimes found in the llvm project openmp.   While flang frontend may not
immediately use clang -cc1 parsing and codegen, the upstream clang driver
already supports a flang toolchain. See clang/lib/Driver/Types.cpp and
clang/lib/Driver/ToolChains/Flang.cpp.

I think it is better for flang to join LLVM sooner than later.  This will
help flang developers better adopt llvm development practices.  For
example, an earlier variant of flang written in c, generated LLVM-IR
without using llvm::IRBuilder.  This is because the origin of that source
was from a non-LLVM project. This architecture was rejected partly because
it was not llvm enough.  This lead to the creation of the f18 C++ project
which will use llvm::IRbuilder.  F18 is the flang that I expect and hope to
land in monorepo next Monday.

I am also AMD's representative to the OpenMP Architecture Review Board.
Adding flang is an important step to completely cover the OpenMP
specification for c, C++, and FORTRAN in LLVM.

I agree, flang has a long way to go.  But I believe there is enough
critical mass with flang to join the LLVM development now.

Thank you

Greg Rodgers
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200108/0a7a4104/attachment.html>

Thanks to everyone for the feedback — both concerns and support. 

Let me add a perspective as someone who has been responsible for helping to
start part of the initial push and finding funding for a portion of the
Flang/f18 efforts to date.  From the outset our mindset was to get Flang to a
point where it was worthy of becoming a part of the LLVM community.  So making
Flang a successful part of the LLVM community has been a major factor in our
viewpoint from the outset.  That may not be reflected in the nature of the code
base as some might prefer to see it today but I personally view the monorepo
landing as the point in time where Flang actually becomes the community’s
project.

For exactly the same reasons Greg mentions, having Flang in the monorepo will
help many of us avoid hassles to be able to contribute to the code base. 
Something that makes the formation of a supporting subset of the community
extremely difficult.  I strongly believe the longer Flang stays separated from
the monorepo the harder it will become to transition — simply because the odds
that the steps taken to meet target deliverables and features won’t necessarily
be addressed as part of the community’s discussions (I think this thread has in
part shown that we’re already here today and need to move beyond it sooner
rather than later).  The steps of landing Flang into the monorepo should simply
be viewed as the very first steps and should in no way be considered to be the
final ones.

Thanks, 

—Pat

> On Jan 8, 2020, at 12:15 PM, Gregory Rodgers via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Hal, Eric, Johannes, David and Peter, 
> 
> I lead the development of OpenMP for AMD GPUs and work with others at AMD
who support OpenMP on AMD CPUs. On behalf of our development teams, we greatly
appreciate your efforts to move the development of flang into a subproject in
the llvm-project repository and to integrate this development effort into the
overall LLVM development community.
> 
> Like most commercial companies, we have certain procedures (some legal) to
participate in open source projects.  Since AMD has already engaged in LLVM
development, adding flang as an LLVM subproject makes it much easier to
participate in the development of flang.    I look forward to my team getting
more involved in the development of flang now that it is part of LLVM.
> 
> I would respectfully disagree with "There's nothing llvm about
it".  Flang uses the clang offloading architecture used by cuda, hip, and
openmp-target.  And the runtime will use both libomp and libomptarget runtimes
found in the llvm project openmp.   While flang frontend may not immediately use
clang -cc1 parsing and codegen, the upstream clang driver already supports a
flang toolchain. See clang/lib/Driver/Types.cpp and 
clang/lib/Driver/ToolChains/Flang.cpp.
> 
> I think it is better for flang to join LLVM sooner than later.  This will
help flang developers better adopt llvm development practices.  For example, an
earlier variant of flang written in c, generated LLVM-IR without using
llvm::IRBuilder.  This is because the origin of that source was from a non-LLVM
project. This architecture was rejected partly because it was not llvm enough. 
This lead to the creation of the f18 C++ project which will use llvm::IRbuilder.
F18 is the flang that I expect and hope to land in monorepo next Monday.
> 
> I am also AMD's representative to the OpenMP Architecture Review Board.
Adding flang is an important step to completely cover the OpenMP specification
for c, C++, and FORTRAN in LLVM.
> 
> I agree, flang has a long way to go.  But I believe there is enough
critical mass with flang to join the LLVM development now.
> 
> Thank you
>  
> Greg Rodgers
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Hi Gregory,

(As a note, you didn't reply to the thread so I didn't see this until
now.)

As I said in my previous thread: "You don't use a single llvm header
anywhere" that's a pretty low bar for "looks like an llvm
project" - and
nothing has changed in the 3 weeks since I sent my earlier message. "We
plan on" isn't a very compelling argument for "looks like
llvm".

As far as the current use in the clang driver: Honestly I don't think you
should be using the clang driver and had I seen I probably wouldn't have
accepted those patches either. I think it would be better off to turn parts
of the driver you might need into a separable library rather than include
fortran support into a "c based languages" driver and will probably
try to
dig up that patch set and comment.

To be clear: I support the idea of a fortran compiler in llvm and
appreciate that you want to do it right. I would like to see a plan of
attack before we talk about imminently putting things in as relying on the
community to adopt llvm development practices and libraries seems to put a
lot of weight in the community rather than on the project that wants to
move in.

Thanks.

-eric


On Wed, Jan 8, 2020 at 11:16 AM Gregory Rodgers via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hal, Eric, Johannes, David and Peter,
>
> I lead the development of OpenMP for AMD GPUs and work with others at AMD
> who support OpenMP on AMD CPUs. On behalf of our development teams, we
> greatly appreciate your efforts to move the development of flang into a
> subproject in the llvm-project repository and to integrate this development
> effort into the overall LLVM development community.
>
> Like most commercial companies, we have certain procedures (some legal) to
> participate in open source projects.  Since AMD has already engaged in LLVM
> development, adding flang as an LLVM subproject makes it much easier to
> participate in the development of flang.    I look forward to my team
> getting more involved in the development of flang now that it is part of
> LLVM.
>
> I would respectfully disagree with "There's nothing llvm about
it".  Flang
> uses the clang offloading architecture used by cuda, hip, and
> openmp-target.  And the runtime will use both libomp and libomptarget
> runtimes found in the llvm project openmp.   While flang frontend may not
> immediately use clang -cc1 parsing and codegen, the upstream clang driver
> already supports a flang toolchain. See clang/lib/Driver/Types.cpp and
> clang/lib/Driver/ToolChains/Flang.cpp.
>
> I think it is better for flang to join LLVM sooner than later.  This will
> help flang developers better adopt llvm development practices.  For
> example, an earlier variant of flang written in c, generated LLVM-IR
> without using llvm::IRBuilder.  This is because the origin of that source
> was from a non-LLVM project. This architecture was rejected partly because
> it was not llvm enough.  This lead to the creation of the f18 C++ project
> which will use llvm::IRbuilder.  F18 is the flang that I expect and hope to
> land in monorepo next Monday.
>
> I am also AMD's representative to the OpenMP Architecture Review Board.
> Adding flang is an important step to completely cover the OpenMP
> specification for c, C++, and FORTRAN in LLVM.
>
> I agree, flang has a long way to go.  But I believe there is enough
> critical mass with flang to join the LLVM development now.
>
> Thank you
>
> Greg Rodgers
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200108/2dbc7ebd/attachment.html>

On Wed, Jan 08, 2020 at 05:35:44PM -0800, Eric Christopher via llvm-dev
wrote:
> As far as the current use in the clang driver: Honestly I don't think
you
> should be using the clang driver and had I seen I probably wouldn't
have
> accepted those patches either. I think it would be better off to turn parts
> of the driver you might need into a separable library rather than include
> fortran support into a "c based languages" driver and will
probably try to
> dig up that patch set and comment.
I disagree on this part quite a bit. First of all, there is quite a bit
code in the wild that expects at least basic support in the "gcc"
frontend for handling Fortran. Additionally, there is a very significant
overlap in the platform handling and little Fortran specific logic
assuming that we don't end up with hundreds of tuning options in the
frontend. That was the biggest concern for me with the first flang
patches to the clang driver: insane amount of fine-tuning flags and
magic number mappings.

Joerg