"Walter Bright"  wrote in message news:maq7ra$2huu$1@digitalmars.com...

> To not inline trivial functions when presented with forceinline would indeed be perverse, and while legally possible as I've said before no compiler writer would do that. Even dmd (!) has no trouble at all inlining trivial functions.

See my alloca example.  I mistrust the inliner because I know has problems.

> But the trouble is, people will use forceinline on very non-trivial functions, and functions where it would actually make things worse, etc., and then to have the compiler error out on them would not be productive.
>
> See the Rust link I provided on experience with the use and misuse of forceinline.

Why do we have inline assembly?  Why do we allow recursion?  We can't stop programmers from doing stupid things, and we shouldn't be trying to. 

On 3 February 2015 at 08:28, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 2/2/2015 8:36 PM, Daniel Murphy wrote:
>>>
>>> If so, what corrective action is the user faced with:
>>
>> The user can modify the code to allow it to be inlined.  There are a huge
>> number
>> of constructs that cause dmd's inliner to completely give up.  If a
>> function
>> _must_ be inlined, the compiler needs to give an error if it fails.
>
>
> I'd like to reexamine those assumptions, and do a little rewinding.
>
> The compiler offers a -inline switch, which will inline everything it can. Performance oriented code will use that switch.
>
> So why doesn't the compiler inline everything anyway? Because there's a downside - it can make code difficult to symbolically debug, and it makes for difficulties in getting good profile data.
>
> Manu was having a problem, though. He wanted inlining turned off globally so he could debug his code, but have it left on for a few functions where not inlining them would make the debug version too slow.
>
> pragma(inline,true) tells the compiler that this function is 'hot', and
> pragma(inline, false) that this function is 'cold'. Knowing the hot and cold
> paths enables the optimizer to do a better job.
>
> There are literally thousands of optimizations applied. Plucking exactly one out and elevating it to a do-or-die status, ignoring the other 999, is a false god. There's far more to a programmer reorganizing his code to make it run faster than just sprinkling it with "forceinline" pixie dust.
>
> There is a lot of value to telling the compiler where the hot and cold parts are, because those cannot be statically determined. But exactly how to achieve that goal really should be left up to the compiler implementer. Doing a better or worse job of that is a quality of implementation issue, not a language specification issue.
>
> Perhaps the fault here is calling it pragma(inline,true). Perhaps if it was
> pragma(hot) and pragma(cold) instead?

pragma(hot/cold) or @attribute(hot/cold)

This maps well in gdc's framework too.

On Tuesday, 3 February 2015 at 09:36:57 UTC, Walter Bright wrote:
> On 2/3/2015 1:11 AM, Mike wrote:
>> All things being equal, will there be any difference between the resulting
>> binaries for each of these scenarios?
>
> No.
>
>> Another way of putting it:  Does pragma(inline, true) simply allow the user to
>> compiler parts of their source file with -inline?
>
> Yes.
>
> I'm beginning to think a pragma(hot, true/false) might be a better approach, as there are more optimizations that can be done better if the compiler knows which branches are hot or not.

I believe both sides in this debate are actually right, but I'm siding with Walter:  pragma(inline, true) should not generate a compiler error if a function cannot be inlined.

The expressed need by the other side is right on, and that need should have be acknowledged.  However, I believe that is a need that Walter did not intend to address with DIP56.

IMO, the important thing to explain in DIP56 is the relationship pragma(inline) has to the -inline compiler flag, and that it is not a substitute for future features that may provide strict enforcement.

It may even be better, and less controversial, to have a pragma(compiler, "-inline -whatever") that gives the user more fine control over, not just -inline, but other compiler options as well...and each compiler flag should have a negative (e.g. -no-inline) conterpart.

I don't like "hot/cold" as it does not convey the effect.

Mike

On Tuesday, 3 February 2015 at 11:33:35 UTC, Mike wrote:
> I don't like "hot/cold" as it does not convey the effect.

Yeah, I believe LLVM has a register saving calling convention that is cold_cc, so "cold" would be more suited for functions that are almost never called.

On Monday, 2 February 2015 at 23:29:26 UTC, Walter Bright wrote:
> Now, when it can't inline, do you expect the compiler to produce an error message?

Just to add support:
Yes, exactly that.

> If so, what corrective action is the user faced with:

Change the function so it can be inlined, or remove the pragma.


Yes, there are many other optimisations that matter, but I think inline is special and so do a bunch of other users.

Just one example:

You write a simple expression that does operation A, in a tight loop.
You look at the assembly and see that it is for some reason terribly unnecessarily slow, especially in debug builds.
To get the sort of asm you want, you implement a rather nasty, messy little function to do the operation, which internally uses intrinsics and/or lots of casts etc. that you don't want lying around in your normal code.
You now have a choice: copy and paste the contents everywhere you need it, or pay for the function call in debug builds (and perhaps optimised too, if the compiler decides it doesn't feel like inlining it).

With an actual guarantee of inlining, the problem goes away. Strap a pragma(always_inline) on the function and carry on.

Hints are great, but sometimes commands are necessary.

Guaranteed inlining makes it possible to have fast debug builds, because it lets you abstract away ugly hand-tuned code at guaranteed zero cost.

On Tuesday, 3 February 2015 at 10:36:08 UTC, Walter Bright wrote:
> Obviously, inlining functions with loops tend to have lower payoffs anyway, because the loop time swamps the function call overhead.

I feel a bit awkward disagreeing with you about a topic like this, because of your obviously huge amount of expertise, but this seems just totally wrong in a few situations:

Combining loops.

Loops where the length is a compile-time constant in the calling context.

Loops where a conditional in the loop is a compile-time constant in the calling context.

On 3 February 2015 at 01:16, John Colvin via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> Can we just have this:
>
> pragma(inline) means "inline it unless you literally can't make it work".
>
> pragma(force_inline) or pragma(always_inline) means "the same as
> pragma(inline), but stop compilation if it can't be inlined".
>
> in the absence of either of these, "inline as you please".
>
>
> A pragma is OK. It will get the job done. People need something to get the job done. If Walter really doesn't like the attribute route then give his taste the benefit of the doubt and let's move on.

Hear hear!
I've been in support of precisely this motion for as long as it's been
on the table.

I'd personally prefer an attribute, and I'll argue for it, but I'll take whatever I can get. Pragma will likely lead to text mixins, and difficulty discovering the state of inline attribution applied to functions. It may lead to meta problems of the type I'm all too frequently familiar with.

"Manu via Digitalmars-d"  wrote in message news:mailman.5832.1422967168.9932.digitalmars-d@puremagic.com...

> I'd personally prefer an attribute, and I'll argue for it, but I'll
> take whatever I can get. Pragma will likely lead to text mixins, and
> difficulty discovering the state of inline attribution applied to
> functions. It may lead to meta problems of the type I'm all too
> frequently familiar with.

Why would you ever want to discover the state of inline attribution?  By definition inlining is supposed it be invisible. 

On 2/3/15 7:39 AM, Manu via Digitalmars-d wrote:
> On 3 February 2015 at 01:16, John Colvin via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> Can we just have this:
>>
>> pragma(inline) means "inline it unless you literally can't make it work".
>>
>> pragma(force_inline) or pragma(always_inline) means "the same as
>> pragma(inline), but stop compilation if it can't be inlined".
>>
>> in the absence of either of these, "inline as you please".
>>
>>
>> A pragma is OK. It will get the job done. People need something to get the
>> job done. If Walter really doesn't like the attribute route then give his
>> taste the benefit of the doubt and let's move on.
>
> Hear hear!
> I've been in support of precisely this motion for as long as it's been
> on the table.
>
> I'd personally prefer an attribute, and I'll argue for it, but I'll
> take whatever I can get. Pragma will likely lead to text mixins, and
> difficulty discovering the state of inline attribution applied to
> functions. It may lead to meta problems of the type I'm all too
> frequently familiar with.
>

To be honest, I thought the debate was more about whether force inline should fail to compile if inlining cannot happen, with Walter thinking it should still compile. But maybe I don't remember it well enough.

-Steve

On 2/2/15 5:34 PM, Jonathan M Davis via Digitalmars-d wrote:
> On Monday, February 02, 2015 13:01:28 Walter Bright via Digitalmars-d wrote:
>> On 2/2/2015 6:43 AM, Manu via Digitalmars-d wrote:
>>> I'm pretty sure the only controversy is that you want it to be a
>>> pragma, everyone else wants it to be an attribute.
>>
>> That's correct.
>>
>> My reasoning is simple - an attribute defines the semantics of the interface, a
>> pragma gives instructions to the compiler, and does not affect logical semantics.
>>
>> For example, attributes change the name mangling, because it affects the
>> semantic interface. A pragma would not.
>
> That makes sense, though the one issue that I see with making it a pragma is
> the fact that pragmas are supposed to be compiler-specific and not part of
> the language (at least as I understand it)

From http://dlang.org/pragma.html#predefined-pragmas:

"All implementations must support these, even if by just ignoring them:"

I would believe that inline would definitely be one that could be ignored, seeing as the code generated whether inlining or not creates the same end result.

But you could put it under that list, and then most compilers will support it. Remember, all 3 major compilers here are based on the same front-end code.

-Steve