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

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

On Wed, Jan 8, 2020 at 5:42 PM Joerg Sonnenberger via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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.
>
>
This is an absolutely fair response, but I think the answer there is making
a lot of the clang driver a library and not having clang support fortran
compilation.

Thanks

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200108/2a695460/attachment.html>

On 1/8/20 7:52 PM, Eric Christopher via llvm-dev wrote:


On Wed, Jan 8, 2020 at 5:42 PM Joerg Sonnenberger via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
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.


This is an absolutely fair response, but I think the answer there is making a
lot of the clang driver a library and not having clang support fortran
compilation.


First, I completely agree that we should have a "frontend driver"
library in LLVM. There are lots of frontends that need to know how to call the
linker and make a executable program, shared library, etc., and we should have
some reusable infrastructure for that.

In this case, however, Fortran is somewhat of a special case for historical
reasons. To emulate gcc, our driver needs to know how to invoke a Fortran
compiler. Considering that, especially considering our long-standing support for
being a driver for gfortran for this reason, and the other similarities in the
compilation models, having this in Clang seems reasonable to me. The reality is
that, in terms of toolchains, the triple of C/C++/Fortran go together for a
significant set of programming environments, and there has long been a coupling
at this driver level (at large).

 -Hal


Thanks

-eric



_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200109/6fe7da1b/attachment.html>