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

[Mahesha HS]

 Dear All,

Thanks for your positive replays. I really value all your inputs so far.
Any product engineering in general can be successful only through
collective effort from right minded and skilled people and co-operation
among them. And, that is why the projects under LLVM compiler
infrastructure are very successful till date.



I have not taken in-depth look into https://github.com/isanbard/flang/.
Will plan to spend some time going through it.



More ever, I belong to a semi-conductor company, where we are currently in
need of a latest standard compliant, LLVM targeted FORTRAN compiler, with
backward compatibility to older standards too. We are currently debating
all possible options as it usually happens in all companies within the
framework of their business models.



So, please give me some time. I will get back to you on this topic. If it
works out well, we all of us put our collective efforts together and make
this project a reality and serves the need of different people like
industry people, academicians, researchers, etc.
--
mahesha


On Sat, Aug 25, 2012 at 12:37 PM, Hal Finkel <hfinkel at anl.gov> wrote:

> 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
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>



-- 
mahesha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120825/cd7dfcb1/attachment.html>