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

Artur Skawina via Digitalmars-d digitalmars-d at puremagic.com
Sun Sep 27 07:48:21 PDT 2015


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)

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


More information about the Digitalmars-d mailing list