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

[Hal Finkel]

On Fri, 24 Aug 2012 17:40:07 -0700
John McCall <rjmccall at apple.com> wrote:

> On Aug 22, 2012, at 8:35 AM, Mahesha HS wrote:
> > I believe that Clang is now in par with other well known industry
> > standard compiler front-ends with compliant to standards, and also
> > far better than other compiler front-ends in few aspects. On the
> > other hand, many industry compiler vendors are started using LLVM
> > internally in their compilers and tools chain for one or the other
> > purpose. Also, many high performance server compiler vendors
> > started looking into LLVM compiler due to various reasons. As all
> > of us know, FORTRAN was and is the language of choice for
> > developing high permanence (scientific) applications, for various
> > known reasons. 
> > 
> > In this line, do you guys think, it is acceptable, if someone
> > seriously start supporting new FORTRAN front-end for LLVM? I
> > understand that Clang, being an umbrella for implementing C family
> > of languages for LLVM, may not cover well, the non C family
> > languages like FORTRAN.
> > 
> > However, I am curious know about the thoughts (positive or
> > negative) of Clang community regarding this topic (need for new
> > FORTRAN front-end for LLVM). If you guys agree that there is a need
> > for it, what is the best way to go about implementing it?, I mean,
> > do we need to completely separate it from Clang project? Or is it
> > possible and is it good to leverage some of the Clang
> > implementation here? In any case, in your experience, how much
> > effort and time duration is required to come-up with a well defined
> > and designed basic infrastructure implementation so that people who
> > are interested can start contributing to it?
> 
> 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?

 -Hal

> In high-performance scientific applications, it is
> going to be extremely valuable to be able to apply high-level
> optimizations to (e.g.) combine operations and eliminate unnecessary
> copies;  those can be straightforward to do in a high-level
> representation, but quite difficult to do after lowering to LLVM IR.
> 
> John.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev



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