[llvm-dev] Flang landing in the monorepo - next Monday!

[Doerfert, Johannes via llvm-dev]

On 01/09, Finkel, Hal J. via llvm-dev wrote:
> 
> 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.

FWIW, that was one of the reasons why we now have `llvm/lib/Frontend`
and the corresponding libraries for the subdirectories.

In addition to frontends, the linker will probably need to know about
various bits, e.g., how to find nvcc, if we have fat-binary/offloading
support in the linker.

Cheers,
  Johannes

> 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).


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200109/30836cd3/attachment.sig>