[LLVMdev] Google SOC - Idea

Duncan Sands baldrick at free.fr
Tue Mar 20 02:48:39 PDT 2007


Hi Scott, I'm currently porting the Ada gcc front-end to LLVM.
This is similar to what you want to do, so here are some comments
from the trenches...

> I plan on first attempting to implement the FORTRAN front-end by
> co-opting the GCC FORTRAN parser.

Good plan.  However the Fortran front-end that comes with gcc 4.0
is known to be weak (llvm-gcc is based on gcc 4.0).  That's because
gcc 4.0 is based internally on a new infrastructure compared to gcc 3.0,
and it took the front-ends a version or two to catch up and sort out
the bugs.  That was the case for Ada too, which is why the first thing
I did was to backport the Ada front-end from gcc 4.3 to llvm-gcc.  I
advise you to backport the gcc 4.2 fortran front-end to llvm-gcc.  For
Ada this was quite easy to do.

Last time I tried to build the fortran front-end in llvm-gcc it got
quite a long way before it died.  This is a good sign.

I've found LLVM to be solid for code that can be produced by C, and
easily fixed for the rest.  There are four classes of problems:
(1) build failures because some tree code is not handled.  CIEL_DIV_EXPR
is an example that is used by Fortran but isn't implemented yet, but these
are usually easy enough to implement (I need to implement this one for Ada,
so we'll see who gets there first!). (2) build failures because you're
outside the world of C.  I suspect Fortran will be less problematic than
Ada, but even in the Ada case the LLVM design has proved sound, and each
problem has individually been simple to fix.  The tricky ones I had were
(a) resolution of forward declarations; (b) handling of exotic packed
bit fields.  (3) build failures due to bugs in gcc 4.0.  It can be tricky
to tell if problems are due to a bug in the front-end or a gcc 4.0 bug.
I had an example with the front-end producing non-constant constructors
for global variables.  It was actually the fault of one of the gcc 4.0
helper routines, and nothing to do with the front-end at all.  These tend
to be fairly easy to fix, because they've usually been fixed in more recent
versions of gcc!  So you have to muck around in gcc 4.2 to find out how
come it works there, then backport the fix.  (4) wrong code.  I haven't
seen many of these.  Having a good testsuite helps to flush these out.
I'm currently working my way through the Ada testsuite, which is quite
comprehensive.  Hopefully the fortran one is too.

> If that fails, I will build a 
> front-end using ANTLR [http://antlr.org] a parser generator with which
> I am familiar and for which a FORTRAN grammar is already available
> (targeting an obsolete version of ANTLR, but it should not be too
> difficult to update).

Bad plan.  I doubt you can build a serious fortran compiler in this way
in the time-frame you are considering.

Good luck!

Duncan.



More information about the llvm-dev mailing list