On 2/2/2015 2:34 PM, Jonathan M Davis via Digitalmars-d wrote:
> 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), and I would expect that anyone
> looking to force inlining would want it guaranteed regardless of the
> compiler. Of course, all compilers could implement it, and with a shared
> frontend for most of the D compilers, it would likely be in most of them
> anyway, but if it's a pragma, it does seem like it wouldn't necessarily be
> guaranteed.

There are already several pragmas implemented. I'd be surprised if some compiler chose not to do them.

As I wrote to Dicebot, compiler implementers aim to please their users as much as possible. They do not attempt to perversely implement the spec in such a way as to conform to the letter but be useless in practice.

For example, I could easily write a Standard conformant C compiler that would be useless. But nobody does such a thing unless they are incompetent, and even if they did, why would anyone waste their time using such a product?

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?

Yes, this is the very point of such feature - telling that if code can't be inlined, it is effectively unusable.

> If so, what corrective action is the user faced with:
>
>    pragma(inline, some expression that determines the compiler version and evaluates to true only if this particular function can be inlined);

Prohibit this generally useless misfeature and keep base semantics useful.

On 03.02.15 00:29, Walter Bright wrote:
>
> Now, when it can't inline, do you expect the compiler to produce an
> error message?

Or warning?

Microcontroller programmers like to look at produced code, no need to force them :)

> Just go with __gshared.

Or even better, avoid globals ;).

"Walter Bright"  wrote in message news:map18m$1dvv$1@digitalmars.com...

> Now, when it can't inline, do you expect the compiler to produce an error message?

Yes.

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

"Johannes Pfau"  wrote in message news:maotpd$1ape$1@digitalmars.com...

> but if you instead write
> @property ref Volatile!ubyte PORTA()
> {
>     return *(cast(Volatile!(ubyte)*)0x05)
> }
>
> PORTA |= now calls a function behind the scenes. The backend does not
> immediately know that &PORTA is always 0x05. Also the this pointer in
> opopAssign is no longer a compile time constant. And this is were the
> constant/runtime value code gen difference discussed above matters.

It may not immediately know, but with guaranteed inlining it becomes a non-issue.

> -O mostly fixes performance problems, but adding an additional property
> function is still much uglier than declaring an extern variable with an
> address in many ways. (compiler bugs, user-facing code, debug info, ...)

I agree that pragma(address) is nicer. 

On 2 Feb 2015 23:45, "Walter Bright via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
> On 2/2/2015 2:30 PM, Johannes Pfau wrote:
>>
>> I does: if the backend can't know that a value is known at compile time it cant use absolute addresses:
>>
>> void test(ubyte* ptr)
>> {
>>      volatileLoad(ptr); //Can't use literal addressing might be runtime
>>      value
>> }
>>
>> The context here is that pragma(address) allows avoiding one wrapper
>> function. See below.
>
>
> Again, that is simply an inlining issue.
>
>
>
>> The pragma(address, 0x05) makes sure that the compiler backend always
>> knows that PORTA is at 0x05.
>
>
> Constant propagation and inlining do that. Both are standard
optimizations that every compiler does. Adding language features on the presumption that compilers won't do that is like trying to fix the broken engine in your car by adding another engine in the trunk.
>
>
>
>> -O mostly fixes performance problems, but adding an additional property function is still much uglier than declaring an extern variable with an address in many ways. (compiler bugs,
>
>
> Language features should not be added because of compiler bugs.
>
>> user-facing code,
>
>
> Library wrapper types will be showing up more and more. How nice they are
is up to the library designer.
>
>
>> debug info, ...)
>
>
> Symbolic debugging is always going to be an issue until there are
debuggers that are better designed to work with D.
>

It's more a marriage than a one way street.  DMD still needs to produce the goods in order for debuggers to turn it into meaningful data.

Iain.

V Mon, 02 Feb 2015 21:53:43 +0000
Dicebot via Digitalmars-d <digitalmars-d@puremagic.com> napsáno:

> On Monday, 2 February 2015 at 21:19:05 UTC, Walter Bright wrote:
> > On 2/2/2015 9:17 AM, H. S. Teoh via Digitalmars-d wrote:
> >> Walter seems to dislike forced inlining for various reasons,
> >> preferring
> >> inlining as a hint at the most, and he probably has a point in
> >> most
> >> cases (let the compiler make the judgment). But in other
> >> cases, such as
> >> the one in question, the user needs to override the compiler's
> >> decision.
> >> Currently there's no way to do that, and it's a showstopper
> >> for those
> >> users.
> >
> > This is a settled issue. After all, I wrote:
> >
> > http://wiki.dlang.org/DIP56
> 
> Erm. Quoting the DIP: "If a pragma specifies always inline, whether or not the target function(s) are actually inlined is implementation defined, although the implementation will be expected to inline it if practical."
> 
> This is exactly the absolutely unacceptable part that makes your DIP useless and last discussion has stalled (from my POV) exactly at the point where you refused to negotiate any compromises on that matter.

Ok why not add some WARN level?

pragma(inline, true, WARN_LEVEL);  // always inline

WARN_LEVEL = 0 // no warning or error is print
WARN_LEVEL = 1 // warning
WARN_LEVEL = 2 // error

It should be easily control by version condition

Am Mon, 02 Feb 2015 15:44:21 -0800
schrieb Walter Bright <newshound2@digitalmars.com>:

> > Also it's a conceptually nice way for typed registers: You can read it as: I've got a Register of type PORT which is an extern variable located add a fixed address. PORT abstract away volatile access.
> 
>      auto a = PORT!0x1234;
> 
> looks nicer than:
> 
>      pragma(address, 0x1234) PORT a;

But because of the every object needs an address rule it wastes at least one byte in the data segment. And your example is actually in TLS.

Well I see that you're not even considering adding a simple pragma to
help embedded programming. In that case I see absolutely no reason to
continue working on that. You guys say "we lack expertise so we cannot
help directly" and you're in "search of champions" for these areas. But
whenever somebody working with D on embedded systems actually comes up
with an issue related to embedded programming and propose solutions you
simply dismiss it. Often even based on vague statements like "that's
not a common task".
http://wiki.dlang.org/Vision/2015H1

pragma(address) could be trivially implemented now and I still think it's a logical extension of the language, whereas global property ref functions for this purpose are just hacks. Till D will have full inline control rust will probably already have all the market share in these areas. At least I'm not willing to invest any more effort into this.

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?