What does 'inline' mean?
Dukc
ajieskola at gmail.com
Mon Jun 8 11:53:47 UTC 2020
On Monday, 8 June 2020 at 06:14:44 UTC, Manu wrote:
> 1. I only want the function to be present in the CALLING
> binary. I do not want an inline function present in the local
> binary where it was defined (unless it was called internally).
> I do not want a linker to see the inline function symbols and
> be able to link to them externally. [This is about linkage and
> controlling the binary or distribution environment]
I think this should be controlled by the visibility attributes,
not `pragma(inline)`. If a function is `private`, there's no
reason why the linker should see it at all. If it's `public`, it
should be seen when linking the internal object files together,
but not when linking a precompiled binary. `export` should always
be visible.
>
> 2. I am unhappy that the optimiser chose to not inline a
> function call, and I want to override that judgement. [This is
> about micro-optimisation]
This is what `pragma(inline)` should be for. For some extent at
least, it also is. If you compile a simple example with `ldc2
-O1`, it'll inline the function if you use the pragma but not
otherwise. `ldc2 -O2` will inline it regardless and DMD will
never do it IIRC, at least not without the `-inline` switch. I
agree that it should.
>
> 3. I want to treat the function like an AST macro; I want the
> function inserted at the callsite, and I want to have total
> confidence in this mechanic. [This is about articulate
> mechanical control over code-gen; ie, I know necessary facts
> about the execution context/callstack that I expect to maintain]
Sounds like a case for mixins, either type of them. But it'd be
better if the compiler would only ignore `pragma(inline, true)`
if either linking externally or avoiding recursion. There's just
no reason to ignore it otherwise. This is an implementation
problem, not a spec problem IMO.
More information about the Digitalmars-d
mailing list