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.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,314d661a32522d8a X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!club-internet.fr!feedme-small.clubint.net!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!border2.nntp.ams.giganews.com!nntp.giganews.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Alex R. Mosteo" Newsgroups: comp.lang.ada Subject: Re: Announcement: GNAT ported to LLVM Date: Thu, 27 Mar 2008 13:43:42 +0100 Message-ID: <651j49F2eaafuU1@mid.individual.net> References: <87iqzco4n7.fsf@willow.rfc1149.net> <7e6246de-2ac0-4311-8047-ae88ea4ccb38@i29g2000prf.googlegroups.com> <76f13aae-d11f-4ffa-b4d1-ad3d597598d8@a70g2000hsh.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: individual.net EDbNdMh5noOdeHMJLt6LVw2mZON1+/E3O6aCF9+EPsz7Au8uE= Cancel-Lock: sha1:DXFo0MUKGp/qJ6+DA/445itjaSM= User-Agent: KNode/0.10.5 Xref: g2news1.google.com comp.lang.ada:20603 Date: 2008-03-27T13:43:42+01:00 List-Id: baldrick wrote: > Hi Gene, > >> I assume that due to the link-time optimization capability that >> inlining among packages will be handled naturally. > > that's correct: you can compile each package to bitcode, then at > link-time they will all be mutually optimized, including inlining > into each other. You can also compile the entire runtime to bitcode > and have that be mutually optimized with your code too. I didn't > turn this on by default because currently link-time-optimization is > not transparent: you have to explicitly call some LLVM tools at link > time. There's a plan to teach llvm-gcc to do this automagically when > you use it to do linking. > >> GNAT-gcc can't do that, right? > > It can to some extent: if you use -O2 -gnatn then it will peek inside > the bodies of packages you are using to try to inline functions. That > functionality becomes a lot less useful now though. > >> This alone ought to be a big deal as accessor/setter >> conventions are leading to programs filled with tiny procedures and >> functions. > > Very true, and I guess that's why ACT implemented -gnatn. I thought that -gnatN was even more aggressive than -gnatn. That said, in my experience, while -gnatn rarely causes bugs to arise, -gnatN causes lots of spurious errors to be reported, forcing to turn it off for many files. Worse still, failure may be triggered by some spec, but is the file with-ing it that must be disabled... In practice I've settled into -O3 -gnatn for optimized builds.