[cfe-dev] Need for new FORTRAN front-end for LLVM ?

[Hal Finkel]

On Sat, 25 Aug 2012 13:52:13 +0700
"C. Bergström" <cbergstrom at pathscale.com> wrote:

> On 08/25/12 01:05 PM, Hal Finkel wrote:
> > On Fri, 24 Aug 2012 17:40:07 -0700
> > John McCall<rjmccall at apple.com>  wrote:
> >
> >> A high-quality LLVM-backed FORTRAN frontend would be great.
> > I strongly agree (and I'd like to work on this as well). I started a
> > discussion about this a few months ago, see:
> > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120430/057199.html
> >
> >>   I do not
> >> think it'd be a good idea in the long run to implement it by
> >> translating FORTRAN into Clang's C ASTs, and there are probably
> >> relatively few things that you could re-use from Clang's source
> >> code.  I recommend using Clang primarily as a design model, rather
> >> than as a shortcut to a working implementation.
> > I think that there are a few things that can be shared, the two
> > largest pieces are probably:
> >
> >   - The driver (both C and family and Fortran share many of the same
> >     requirements for finding basic system libraries and tools and
> >     running them)
> >
> >   - The C preprocessor (any production Fortran compiler needs a C
> >     preprocessor (with slightly-modified tokenization rules). With
> > some refactoring, this should also be shared.
> >
> >> If you're seriously interested in this, there are ways that we
> >> could suggest to *improve* on Clang as an implementation model.  In
> >> particular, I would recommend introducing a third IR, so that the
> >> translation goes like so: source code ->  AST ->  high-level IR
> >> ->  LLVM IR ->  machine code
> > Do you view this high-level IR as being C-ish in scope (with better
> > aliasing rules)? For example, do you think that array slices will be
> > expanded at this high-level IR, or would that wait until CodeGen?
> * I'm willing to *pay* someone to work on the parsing and sema
> aspects of this.  We (PathScale) however require support for F90, 95,
> 2003 and 2008 though.  So while "modern" Fortran may have a lot of
> the same OO design principles there's still some legacy involved with
> the older standards.  (Anyone thinking they don't have to support
> F95+ is kidding themselves - there's just too much legacy code out
> there if you want it to actually be used)

There is a bunch of Fortran 77 out there too ;)

> 
> * Have you looked or considered contributing to Bill's work?
> https://github.com/isanbard/flang/

I think that this is a good start, but the highest-productivity
solution will require a greater reuse of clang components (driver,
preprocessor, etc.).

> 
> * I fully agree with John that a higher level IR is necessary, but I 
> view AST->IR generation to be a separate project in itself.  Thinking
> of the high-level IR as C-ish is fundamentally flawed.

I wouldn't go that far ;) -- at some point the array slicing semantics
need to be lowered into explicit allocations, loops, etc. and so my
question is, specifically, where does that happen. Regardless, I
certainly agree that we'll want higher-level transformations prior to
that lowering.

 -Hal

>  Fortran
> treats arrays as 1st class citizens and trying to code Fortran
> C-style is just wrong. (imho)
> 
> For anyone interested in working on sema/parsing - I have private 
> testsuites which extensively cover the various Fortran standards.
> ping me offlist to coordinate.
> 
> Best,
> 
> ./C
> 



-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory