Am Sat, 26 Sep 2015 12:21:15 +0200
schrieb Jacob Carlborg <doob@me.com>:

> On 2015-09-26 06:27, Manu via Digitalmars-d wrote:
> 
> > We _really_ need attribute aliasing in
> > some form, especially since LDC/GDC have compiler-specific attributes
> > that DMD doesn't recognise.
> 
> I'm not sure how much this helps but can't you use a dummy UDA on DMD for the GDC/LDC attributes?

pragma(inline, true) void foo() @gcc.attribute.attribute("forceinline") @ldc.attribute.attribute("alwaysinline") @safe pure nothrow @nogc
{
	// Ok, what did I want this to do again ... ?
}

Maybe the compiler devs can decide on more common syntax like a generic core.attribute or just use pragma for inlining, but extend it so that it offers more options:

* no
* force
* flatten
(And maybe an additional 'allow' that convinces the compiler
 that inlining is safe.)

-- 
Marco

Am Sat, 26 Sep 2015 18:42:03 +0200
schrieb Marco Leise <Marco.Leise@gmx.de>:

> Am Sat, 26 Sep 2015 12:21:15 +0200
> schrieb Jacob Carlborg <doob@me.com>:
> 
> > On 2015-09-26 06:27, Manu via Digitalmars-d wrote:
> > 
> > > We _really_ need attribute aliasing in
> > > some form, especially since LDC/GDC have compiler-specific
> > > attributes that DMD doesn't recognise.
> > 
> > I'm not sure how much this helps but can't you use a dummy UDA on DMD for the GDC/LDC attributes?
> 
> pragma(inline, true) void foo()
> @gcc.attribute.attribute("forceinline")
> @ldc.attribute.attribute("alwaysinline") @safe pure nothrow @nogc
> { // Ok, what did I want this to do again ... ? }
> 

module myinline;

static if(WhateverConditionIWant || SomeOtherCondition)
{
    struct forceinline {} //no-op
}
else
{
    version (GNU)
    {
        alias forceinline = gcc.attribute.attribute("forceinline");
    }
    else version (LDC)
    {
        alias forceinline = ldc.attribute.attribute("alwaysinline");
    }
    else version (DMD)
    {
        alias forceinline = pragma... //Damn, DMD!
    }
}

@forceinline @safe pure nothrow @nogc foo()
{

}

> Maybe the compiler devs can decide on more common syntax like a generic core.attribute or just use pragma for inlining, but extend it so that it offers more options:
> 
> * no
> * force
> * flatten
> (And maybe an additional 'allow' that convinces the compiler
>  that inlining is safe.)
> 

We proposed implementing a generic core.attribute for some time now but the DMD devs weren't very enthusiastic about this.

If you ask me, we should get rid of pragmas wherever possible. UDAs do
look better, are composable and just like pragmas do not pollute
namespaces. (@mangle("foo") instead of pragma(mangle, "foo")...

One thing missing though is UDAs for modules.

On 09/26/15 18:42, Marco Leise via Digitalmars-d wrote:
> Am Sat, 26 Sep 2015 12:21:15 +0200
> schrieb Jacob Carlborg <doob@me.com>:
> 
>> On 2015-09-26 06:27, Manu via Digitalmars-d wrote:
>>
>>> We _really_ need attribute aliasing in
>>> some form, especially since LDC/GDC have compiler-specific attributes
>>> that DMD doesn't recognise.
>>
>> I'm not sure how much this helps but can't you use a dummy UDA on DMD for the GDC/LDC attributes?
> 
> pragma(inline, true) void foo() @gcc.attribute.attribute("forceinline") @ldc.attribute.attribute("alwaysinline") @safe pure nothrow @nogc
> {
> 	// Ok, what did I want this to do again ... ?
> }

It's more like:

 pragma(inline, true) void foo() @inline @safe pure nothrow @nogc
 {
 	// Ok, what did I want this to do again ... ?
 }

where `inline` would be aliased to the right LDC/GDC attribute.


> Maybe the compiler devs can decide on more common syntax like a generic core.attribute or just use pragma for inlining, but

No, `pragma` can not be conditionally enabled or aliased.

It does not work well in D, except in cases it's used to extend
the language in a non-implementation-specific way.
(C/C++ have the preprocessor, that's why it works there)


> extend it so that it offers more options:
> 
> * no
> * force
> * flatten
> (And maybe an additional 'allow' that convinces the compiler
>  that inlining is safe.)

`allow` is the default state and always safe; for the cases where it's /undesirable/, there is noinline.

artur

On 2015-09-26 18:42, Marco Leise wrote:

> Maybe the compiler devs can decide on more common syntax like
> a generic core.attribute or just use pragma for inlining, but
> extend it so that it offers more options:

Yeah, we already have core.attribute. Now they just have to agree on the name :)

-- 
/Jacob Carlborg

Am Sat, 26 Sep 2015 21:11:07 +0200
schrieb Jacob Carlborg <doob@me.com>:

> On 2015-09-26 18:42, Marco Leise wrote:
> 
> > Maybe the compiler devs can decide on more common syntax like a generic core.attribute or just use pragma for inlining, but extend it so that it offers more options:
> 
> Yeah, we already have core.attribute. Now they just have to agree on the name :)

*nods*

So ...

agree already guys.

Guys?!

-- 
Marco

Am Sat, 26 Sep 2015 19:58:14 +0200
schrieb Artur Skawina via Digitalmars-d
<digitalmars-d@puremagic.com>:

> `allow` is the default state and always safe; for the cases where it's /undesirable/, there is noinline.
> 
> artur

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.

-- 
Marco

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@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

Am Sun, 27 Sep 2015 16:48:21 +0200
schrieb Artur Skawina via Digitalmars-d
<digitalmars-d@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@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