On Tuesday, February 03, 2015 11:41:35 via Digitalmars-d wrote:
> 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.

Well, as far as I can tell, that's pretty much exactly what Walter meant by "hot" and "cold" - how likely they are to be called, with the idea that the compiler could then use that information to better optimize - be it inlining or some other optimization.

- Jonathan M Davis

On 3 February 2015 at 23:27, Daniel Murphy via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> "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.

In the inevitable case that I always seem to find myself in, where I'm
wrapping something in a thin shim that should behave IDENTICAL to the
thing I'm wrapping.
It's the source of the vast majority of my language issues.

"Andrei Alexandrescu"  wrote in message news:mar39k$hvh$1@digitalmars.com...

> I think the best route here - and the most in-the-spirit-of-D - is to provide introspection on whether a function is being inlined or not. Then we can always have in libraries:
>
> bool uart(ubyte b)
> {
>      static assert(__traits(inlined),
>        "Inlining of uart() must be supported.");
>      ...
> }

That would require that inlining is done in the frontend, which is not acceptable. 

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

> In the inevitable case that I always seem to find myself in, where I'm
> wrapping something in a thin shim that should behave IDENTICAL to the
> thing I'm wrapping.
> It's the source of the vast majority of my language issues.

If it's a thin shim, why would you _not_ want it inlined?  I guessed you would say that, but it doesn't seem to be the same as matching arg types and attributes. 

On 2/3/15 9:05 PM, Daniel Murphy wrote:
> "Andrei Alexandrescu"  wrote in message
> news:mar39k$hvh$1@digitalmars.com...
>
>> I think the best route here - and the most in-the-spirit-of-D - is to
>> provide introspection on whether a function is being inlined or not.
>> Then we can always have in libraries:
>>
>> bool uart(ubyte b)
>> {
>>      static assert(__traits(inlined),
>>        "Inlining of uart() must be supported.");
>>      ...
>> }
>
> That would require that inlining is done in the frontend, which is not
> acceptable.

Yah, won't fly. Sorry for the distraction. -- Andrei

On Tuesday, 3 February 2015 at 22:41:30 UTC, Jonathan M Davis wrote:
> Well, as far as I can tell, that's pretty much exactly what Walter meant by
> "hot" and "cold" - how likely they are to be called, with the idea that the
> compiler could then use that information to better optimize - be it inlining
> or some other optimization.

But "hot" does not imply inlining. You might want to tell the compiler that a function should use "hot" function call mechanics and never inline (for pragmatic reasons, like injecting breakpoints).

On 4 February 2015 at 15:16, Daniel Murphy via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> "Manu via Digitalmars-d"  wrote in message news:mailman.5867.1423017226.9932.digitalmars-d@puremagic.com...
>
>> In the inevitable case that I always seem to find myself in, where I'm
>> wrapping something in a thin shim that should behave IDENTICAL to the
>> thing I'm wrapping.
>> It's the source of the vast majority of my language issues.
>
>
> If it's a thin shim, why would you _not_ want it inlined?  I guessed you would say that, but it doesn't seem to be the same as matching arg types and attributes.

And you have a very fair point. I just have a feeling it's likely to
come up, considering my extensive experiences with other similarly
awkward features.
This is why I'm nowhere near as emotional about this as other issues I
have a stake in. I do just want to see resolution.

On 3 February 2015 at 11:15, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
> 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.

Also 'flatten' - which allows you to control inlining at the caller, rather than the callee.