octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: symtab.h: why so many function bodies


From: Rik
Subject: Re: symtab.h: why so many function bodies
Date: Wed, 24 Feb 2016 09:24:13 -0800

On 02/24/2016 06:29 AM, address@hidden wrote:
Subject:
Re: symtab.h: why so many function bodies
From:
Olaf Till <address@hidden>
Date:
02/24/2016 12:52 AM
To:
LachlanA <address@hidden>
CC:
address@hidden
List-Post:
<mailto:address@hidden>
Precedence:
list
MIME-Version:
1.0
References:
<address@hidden>
In-Reply-To:
<address@hidden>
Message-ID:
<address@hidden>
Content-Type:
multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT"
Message:
7

On Tue, Feb 23, 2016 at 08:23:05PM -0800, LachlanA wrote:
> Why are so many of the functions in   class symbol_table   defined in
> symtab.h instead of symtab.cc?   Since many files include symtab.h, there
> seems to be an unnecessary amount of recompiling when debugging those
> functions.
> 
> If it is to make the code inline, wouldn't declaring it as inline would be
> just as effective?
No, code can't be made inline outside the object in which it is
compiled, can it? You have to compile the code in each object in which
you want to have it inline ...

In general this is correct.  Inlining is usually restricted to the translation unit of the compiler (roughly one file of code after the pre-processor has run and all #include and #ifdef directives have been processed).  However, there are compiler/linkers that can inline functions across multiple translation units (Link-Time Optimization).  GCC is one of them with the -flto flag.  See this discussion on Stack Overflow: http://stackoverflow.com/questions/5987020/can-the-linker-inline-functions.

But your point may be valid nevertheless, the question is whether such
larger functions benefit sufficiently from being inlined to effort
compiling them again.

In the same vein, I think it would be good to start using visibility attributes in Octave.  The system is already largely in place with the decoration OCTAVE_API at the front of functions which are to have external linkage (visible to others).  However, we only invoke the system on Windows platforms.  My guess is that the the linker symbol table is crowded with a bunch of functions that are never called outside of a single translation unit (static file scope).  This increases the sizes of the object files and probably makes the linker work a bit harder to read, but never use, these definitions.

--Rik

reply via email to

[Prev in Thread] Current Thread [Next in Thread]