LLVM and gfortran ?

[john.chl...@gmail.com]

What exactly is the relationship between LLVM include Objective-C, Fortran, and gfortran? Searching the web I get such statements as: LLVM includes Objective-C, Fortran, ...

Does gfortran provide a compiler front-end for LLVM ?


---John

[john.chl...@gmail.com]

Accidental paste error; should be: What exactly is the relationship between LLVM and gfortran?

[David Duffy]

On Fri, 25 Jan 2013, john.chl...@gmail.com wrote:

> Accidental paste error; should be: What exactly is the relationship between LLVM and gfortran?

http://dragonegg.llvm.org/

[john.chl...@gmail.com]

On Saturday, January 26, 2013 3:50:37 AM UTC-5, David Duffy wrote:

> On Fri, 25 Jan 2013, ...@gmail.com wrote:
>
>
> > Accidental paste error; should be: What exactly is the relationship between LLVM and gfortran?
>
>
> http://dragonegg.llvm.org/

Which does better with code generation?

[Tobias Burnus]

john.chl...@gmail.com wrote:
> What exactly is the relationship between LLVM include Objective-C, Fortran, and gfortran?

gfortran itself is (only) a front end to GCC and is is part of GCC.****

LLVM itself does not have a Fortran compiler; however, as David already
mentioned, a GCC plugin exists ("draggon egg"), which converts the
internal representation of GCC ("GIMPLE") into the internal
representation of LLVM.

As GCC's internal representation is not completely set in stone, there
is the chance that at least not all features are taken care of (e.g.
"INTENT(IN)" comes into my mind). The web page also indicates that 4.7
is not fully supported and doesn't mention 4.8. Though, I assume that
most of the time it works well.

> Which does better with code generation?

I think in general GCC is regarded to produce faster code than LLVM -
and it supports more architectures. As always, it depends on the
specific code and options whether one compiler or another produces
faster code.

Unless you have a special reason to prefer LLVM, using GCC should be the
better option for Fortran as gfortran/GCC is more widely used, belongs
to one package and is more active tested. If you find a bug using
gfortran + draggon egg + LLVM, the bug can be in either of the three
packages.

The advantage of LLVM is a license,* which makes it easier to use it in
close-source applications, and the use of C++ through out. (Some might
regard both as disadvantage.) Additionally, with LLVM, the parts of the
compiler (LLVM-specific front ends, LLVM itself etc.) are better usable
as library - instead of as compiler.** Unless you want to use it for
syntax highlighting, static analysis etc., it shouldn't matter for you.
(Additionally, as LLVM is newer it is regarded by some per se as better. ;-)

Additionally, CLANG - a C/C++ front end, which currently generates as
output an intermediate representation for LLVM, is more suitable that
GCC's C/C++ compiler for being used as library, e.g. for syntax
highlighting or parsing C/C++ on the fly. It has also some static
analysis, which goes a bit beyond GCC - and diagnostic output which is
sometimes better (and sometimes inferior) to C/C++'s output.*** (Side
remark: There is no reason why one couldn't create a version of CLANG
which generates output for GCC's GIMPLE, but no one did so.)

Thus, for C/C++, using CLANG+LLVM instead of (or in addition to) GCC's
gcc/g++ can be useful. Using gfortran+DraggonEgg+LLVM usually doesn't
make much sense.

(Actually, one reason to use it could be the one wants to use CLANG+LLVM
- with some Fortran code. Using gfortran+DraggonEgg+LLVM allows
cross-file optimization (LTO = link-time optimization/multi-file IPA,
IPA = interprocedural analysis), which is not possible when mixing GCC
and LLVM compiled code.)


Tobias

**** gfortran (as g77 did before) started as GCC front end but outside
of the general GCC tree. Thus, that's possible as well. Being in-tree
ensures that it automatically gets modified to middle-end changes and
means that Fortran code (as far as it is covered by GCC's test suite)
should never break.

* I think the license was the main reason that Apple has started the
work on CLANG/LLVM. If I am informed correctly, Apple still uses GCC for
the ARM hardware such as the iPhone/iPad, but I might be wrong.

** There are two reasons for the better library use: One is that the
code is newer and the other is that the makers of LLVM were allowing
from the beginning for a rather defined intermediate representation. For
GCC, the license owner - the Free Software Foundation - feared that GCC
output could be used by close-source software to generate optimized
code, which went against the free-software spirit of the FSF. With the
GNU Public License 3 the hope to have fixed this such that GCC now also
allows to use plugins. Codewise, GCC internally slowly moves to a more
modular code. [And LLVM gets a bit messier internally while it matures
and produces better code.]

*** One reason that CLANG is better suited for external use (syntax
highlighting etc.) is that the internal code representation keeps
information about the C/C++ internal representation much longer than in
GCC, where the representation is soon lowered to a generic
representation. That's fine for code generation but less suited for
other purpose. CLANG had for a while also better diagnostic output, but
I think that's no longer the case - but GCC has caught up. Here, one
sees the effect of friendly competition.