[RFC] Adding support for the flang toolchain

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[RFC] Adding support for the flang toolchain

Louis Dionne via cfe-dev

Hi all,

As you may recall, the flang compiler by PGI is a new frontend for LLVM that, unlike past efforts, has the potential provide equal or even superior fortran support compared to other compilers (such as gfortran).

To add support for this new compiler, PGI needed to make certain modifications to the drivers that clang supports, particularly to allow clang to invoke the fortran frontend executables and the linker with the correct command-line arguments. We (myself as a lowly contributor and PGI) think that it makes sense to push these modifications upstream to ease and consolidate clang maintenance.

To be absolutely clear, this would NOT introduce a new burden on clang maintainers to also support a fortran compiler. To the extent that this would introduce a new burden, it would be limited to maintaining a stable command-line interface to the fortran frontend executables, the same as has been done for something like ‘link.exe’.

Please excuse incorrect formatting, as I am new to the cfe-dev list.


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Adding support for the flang toolchain

Louis Dionne via cfe-dev
On Sun, Dec 17, 2017 at 11:02:37PM -0600, xoviat via cfe-dev wrote:
> To add support for this new compiler, PGI needed to make certain
> modifications to the drivers that clang supports, particularly to allow
> clang to invoke the fortran frontend executables and the linker with the
> correct command-line arguments. We (myself as a lowly contributor and PGI)
> think that it makes sense to push these modifications upstream to ease and
> consolidate clang maintenance.

I did a review of the changes half a year ago. There was quite a bit of
unnecessary churn in the repo. The biggest problem from my perspective
is the massive use of magic numbers in the interface. I think that part
should be fixed on the flang side before talking about merging the
patches.

Joerg
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Adding support for the flang toolchain

Louis Dionne via cfe-dev
> I did a review of the changes half a year ago. There was quite a bit of
> unnecessary churn in the repo. The biggest problem from my perspective
> is the massive use of magic numbers in the interface. I think that part
> should be fixed on the flang side before talking about merging the
> patches.

For the record, the churn has settled down quite a bit (maybe ~15 lines of changes per month now). The magic numbers still appear to be present though; that would need to be fixed. However, while that's in progress, are there any other potential issues that need to be resolved as well (I'd like to tackle them all at once rather than iterating)?

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Adding support for the flang toolchain

Louis Dionne via cfe-dev
On Mon, Dec 18, 2017 at 05:40:31PM -0600, xoviat wrote:
> > I did a review of the changes half a year ago. There was quite a bit of
> > unnecessary churn in the repo. The biggest problem from my perspective
> > is the massive use of magic numbers in the interface. I think that part
> > should be fixed on the flang side before talking about merging the
> > patches.
>
> For the record, the churn has settled down quite a bit (maybe ~15 lines of
> changes per month now).

I meant more that the clang fork contained quite a few purely cosmetical
changes, not that it changed regulary.

> The magic numbers still appear to be present though; that would need to
> be fixed. However, while that's in progress, are there any other
> potential issues that need to be resolved as well (I'd like
> to tackle them all at once rather than iterating)?

Iteration is likely unavoidable. Ideally, a large part of the option
handling should be table-driven and not hard-coded. The toolchain part
needed a lot of refactoring in the version I checked.

One high-level question is whether shoe-horning the
gfortran-compatibility interface into the clang driver is really
desirable. I.e. it is a mostly orthogonal set of command line flags and
that seems pretty bad from a design perspective. It's likely going to
repeat the problems of clang-cl.exe over and over again. I'd like some
input from folks like Hal on the impact on the UX here. In other words,
I wonder if having a consistent and integrated approach and maybe a
compat-wrapper script as flang isn't better long term.

Joerg
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Adding support for the flang toolchain

Louis Dionne via cfe-dev

On 12/18/2017 06:29 PM, Joerg Sonnenberger via cfe-dev wrote:

> On Mon, Dec 18, 2017 at 05:40:31PM -0600, xoviat wrote:
>>> I did a review of the changes half a year ago. There was quite a bit of
>>> unnecessary churn in the repo. The biggest problem from my perspective
>>> is the massive use of magic numbers in the interface. I think that part
>>> should be fixed on the flang side before talking about merging the
>>> patches.
>> For the record, the churn has settled down quite a bit (maybe ~15 lines of
>> changes per month now).
> I meant more that the clang fork contained quite a few purely cosmetical
> changes, not that it changed regulary.

I'm pretty sure that I had them remove those some months ago.

>
>> The magic numbers still appear to be present though; that would need to
>> be fixed. However, while that's in progress, are there any other
>> potential issues that need to be resolved as well (I'd like
>> to tackle them all at once rather than iterating)?
> Iteration is likely unavoidable. Ideally, a large part of the option
> handling should be table-driven and not hard-coded. The toolchain part
> needed a lot of refactoring in the version I checked.
>
> One high-level question is whether shoe-horning the
> gfortran-compatibility interface into the clang driver is really
> desirable. I.e. it is a mostly orthogonal set of command line flags and
> that seems pretty bad from a design perspective. It's likely going to
> repeat the problems of clang-cl.exe over and over again. I'd like some
> input from folks like Hal on the impact on the UX here. In other words,
> I wonder if having a consistent and integrated approach and maybe a
> compat-wrapper script as flang isn't better long term.

First, Clang currently can serve as a gfortran driver. One question we
need to answer, if we move forward to integrating Flang support into
Clang, is what to do with the gfortran-driving capability. I'd recommend
that, at least in the short/medium-term, we add some flag to switch
which compiler is used by default for Fortran code. I don't think having
"flang foo.f90" use flang and "clang foo.f90" use gfortran is desirable.

Flang needs a driver, and that driver needs to find system libraries,
sanitizer libraries, include directories, and so on. It needs large
parts, perhaps nearly all, of what Clang's driver does. As a result, I
think that it makes sense to reuse that code. Given that Clang already
processes gfortran options (because it can serve as a gfortran driver),
extending the command-line options in this regard does not seem
problematic. Regarding the orthogonality of the command-line options, we
probably should segregate any Fortran-specific options into a separate
.td file (regardless of what happens with Flang) - I agree that having
them mixed in with everything else is suboptimal.

Regarding clang-cl, I actually find the command-line-options personality
capability a strength of Clang (although it can be painful).
Nevertheless, I don't think that's what we're talking about here.

Thanks again,
Hal

>
> Joerg
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Adding support for the flang toolchain

Louis Dionne via cfe-dev
Changes to user-facing command-line options for flang will be somewhat painful now and even more painful as we go along -- flang has already been integrated into some upstream build systems with the expectation that compiler options will not change. Having said that, changing the command-line interface may still be justified but I'd like to pin this down now so that we can avoid even more future pain. 

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Adding support for the flang toolchain

Louis Dionne via cfe-dev
On 12/20/2017 08:20 PM, xoviat wrote:
> Changes to user-facing command-line options for flang will be somewhat
> painful now and even more painful as we go along -- flang has already
> been integrated into some upstream build systems with the expectation
> that compiler options will not change. Having said that, changing the
> command-line interface may still be justified but I'd like to pin this
> down now so that we can avoid even more future pain.

We'll need to come up with a plan for the style of command-line options
and if/how to support other dialects. I'd recommend giving first
priority to gfortran-compatible flags, as that's likely most convenient
to both us (because we already support most of them, especially those
common with gcc/g++) and a majority of our users (most of whom already
have some build configuration that works with gfortran). New flags
should be added consist with our general conventions.

The current mix of gfortran-style and PGI-style flags doesn't clearly
serve anyone well. I agree, however, that we should nail this down
sooner rather than later.

  -Hal

--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev