From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_00,INVALID_MSGID, MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,4b12a5cee4778f63 X-Google-Attributes: gid103376,public From: Robert Dewar Subject: Re: GNAT & GCC performace (bad news) Date: 1999/12/07 Message-ID: <82hn65$a5o$1@nnrp1.deja.com>#1/1 X-Deja-AN: 557310496 References: <38473D90.68D8F47@acenet.com.au> <1999Dec3.103807.1@eisner> <82fgh2$mt3$1@nnrp1.deja.com> <1999Dec6.073729.1@eisner> X-Http-Proxy: 1.0 x26.deja.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja.com - Before you buy. X-Article-Creation-Date: Tue Dec 07 01:16:57 1999 GMT X-MyDeja-Info: XMYDJUIDrobert_dewar Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.04 [en] (OS/2; I) Date: 1999-12-07T00:00:00+00:00 List-Id: In article , Robert A Duff 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.