Re: Announcement: GNAT ported to LLVM

["Alex R. Mosteo" <devnull@mailinator.com>]

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.