pragma(inline, true) not very useful in its current state?

[Marco Leise via Digitalmars-d]

Am Sun, 27 Sep 2015 16:48:21 +0200
schrieb Artur Skawina via Digitalmars-d
<digitalmars-d at puremagic.com>:

> On 09/27/15 13:48, Marco Leise via Digitalmars-d wrote:
> > Am Sat, 26 Sep 2015 19:58:14 +0200
> > schrieb Artur Skawina via Digitalmars-d
> > <digitalmars-d at puremagic.com>:
> > 
> >> `allow` is the default state and always safe; for the cases
> >> where it's /undesirable/, there is noinline.
> > 
> > No what I meant was when the compiler sees inline assembly or
> > anything else it deems not safe to inline, you can convice it
> > anyways. It is more like @trusted on otherwise @system
> > functions. I just mentioned it so it is under consideration,
> > as I have seen it in LLVM.
> 
> The problem with this would be that it would soon lead to a
> C-like mess -- a lot of function marked with `allow` just-in-case.
> Failure to inline is a compiler implementation problem, it
> shouldn't affect the language, which already has enough
> annotation noise.
> What would be the cases for `allow`, that are /not/ caused
> by compiler limitations? (dmd's legacy inline asm hack is not
> part of the language in practice, so that does not count)

I have no idea, ask the LLVM team for more information. At
least as I understood it would be a rare need. A stupid
example would be alloca(). Functions that contain it are not
inlined and that is not a compiler limitation. Now you might
manipulate the stack pointer in asm and the compiler could
stop inlining although you know it is safe. Something like
that maybe.

> Also keep in mind that `noinline` will often not come alone,
> but be accompanied by other annotations like `noclone`.
> `noinline` often means that the functions identity matters,
> so you have to disable cross-function constant propagation
> etc too. It can all be done by bundling the attributes via
> alias, but the defaults must be sane, so that most code
> does not need annotations (for example: a templated function
> containing a mixin must not require @inlinable @clonable @etc
> just because the mixed in code, that is not locally known,
> /might/ silently turn off inlining).
> 
> artur

In general I don't see inlining attributes much used at all
because of the sane defaults we already have and the
aggressive inlining performed by modern compilers.
For me the option to build a release version and mark a single
function "noinline" is interesting to see it as a separate
item in a profiler or to set a breakpoint on it in a
debugger and see all the assembly as one block.

But first we need to agree on names in core.attribute.
I find the GCC names pretty good. "force" is stronger than
"always". Unless, to support DMD, we want a more fuzzy thing
that doesn't really enforce anything unless -inline is active.

-- 
Marco