Re: GNAT & GCC performace (bad news)

[Robert Dewar <dewar@gnat.com>]

In article <wcchfhwm64u.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> Averstar's Ada-to-C compiler does Ada-specific optimizations,
> such as removing constraint checks based on flow analysis, in
> the front end.  It relies on the C compiler for the kinds of
> optimizations that C compilers typically do.

This approach is of course pragmatically valuable for providing
Ada for a wide range of machines for which Ada would not
otherwise be available.

However, it is fundamentally flawed in terms of achieving the
best possible efficiency, and surely this approach would never
be chosen except for the pragmatic considerations of the
previous paragraph.

Why?

The trouble is that a lot of information is lost in going from
Ada to C. In particular, the typing information, which is
extremely valuable for many kinds of optimization (e.g. alias
analysis) is simply lost in the translation to C.

There are many other similar instances where the information
available to a true Ada compiler allows optimizations that
are simply not possible once the information is lost by
translation to C.

One very significant area is nested procedures. There are
compilation approaches which generate extremely efficient code
for nested procedures, but since C has not nested procedures,
the Ada front end must "fake" the access to nested procedures.
This means typically that you end up having to address local
variables in an inefficient manner that may well disrupt the
register allocation phase of the target C compiler. There are
basically two ways of faking nested procedures, either by
using address vectors (which tend to force locals into memory)
or my representing the locals as fields of a record (and many
compilers will not treat such fields nearly as efficiently as
stand alone local variables).

Is this significant in practice? Hard to say, optimizations are
generally disappointing :-) in that they do not achieve amazing
improvements hoped for.

Nevertheless, I think in practice you will find that the hybrid
approach is often disappointing. Indeed Tuck mentioned to me
that Intermetrics had been disappointed in at least one C
compiler that they were using as a back end.

Most certainly in the case of GNAT we would lose by translating
to C and then going through the C compiler. A number of
important optimizations would be lost for high level Ada code
if we followed this approach.

Of course compilers can vary hugely in quality, and in
particular it is the case that a given compiler may be uneven,
and generate great code for some things, and not nearly so good
code for other things. This is certainly true for GNAT, we are
constantly improving the code quality (which would not be
possible if GNAT generated perfect code in all cases :-)

Robert Dewar
Ada Core Technologies


Sent via Deja.com http://www.deja.com/
Before you buy.