Re: DIP56 - inlining
On 2/3/15 5:29 PM, Walter Bright wrote: http://wiki.dlang.org/DIP56 There's been enough discussion, time to make a decision and move on. I changed the description to: If a pragma specifies always inline, and the compiler cannot inline it, a warning will be generated. Implementations will likely vary in their ability to inline. Some details need to be explained, but I think this looks fine to me. Please put in an example for each rule, that will probably help the details. -Steve
Re: DIP56 - inlining
On 2/4/15 1:46 AM, Zach the Mystic wrote: On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP56 There's been enough discussion, time to make a decision and move on. I changed the description to: If a pragma specifies always inline, and the compiler cannot inline it, a warning will be generated. Implementations will likely vary in their ability to inline. It's a bikeshed argument, but why not: pragma(inline, always); // warn if unable to inline pragma(inline, never); pragma(inline);// revert to default behavior ? I know `true` and `false` are keywords, but why confuse people? What is a true inline? enum always = true; enum never = false; -Steve
Re: DIP56 - inlining
On Thursday, 5 February 2015 at 14:43:40 UTC, Steven
Schveighoffer wrote:
On 2/4/15 1:46 AM, Zach the Mystic wrote:
It's a bikeshed argument, but why not:
pragma(inline, always); // warn if unable to inline
pragma(inline, never);
pragma(inline);// revert to default behavior
?
I know `true` and `false` are keywords, but why confuse
people? What is
a true inline?
enum always = true;
enum never = false;
-Steve
Actually, the better reason is that, as subsequently clarified,
the pragma accepts a boolean expression, rather than just `true`
or `false`, allowing for greater flexibility. Accepting an
integer, for 3+ inlining strategies, would allow even more, but
it might not carry its own weight (same with enum always = true;,
because of namespace pollution). My gut says that an integer is
better, but I don't know if there really are more than 3 good
inlining strategies.
A more general approach would be:
enum {
inlineOff,
inlineOn,
inlineDefault,
codePathHot,
codePathCold
}
pragma(optimize, inlineOn);
pragma(optimize, codePathHot);
You'd get everything here, with options to add more later. Note
that codePathCold/Hot need not cancel inlineOff/On/Default, as
they could be implemented as orthogonally.
Re: DIP56 - inlining
On Wednesday, 4 February 2015 at 21:05:59 UTC, Zach the Mystic wrote: On Wednesday, 4 February 2015 at 20:09:04 UTC, Walter Bright wrote: On 2/4/2015 8:29 AM, Andrei Alexandrescu wrote: On 2/4/15 4:02 AM, Walter Bright wrote: On 2/4/2015 1:39 AM, ponce wrote: Would pragma(inline, bool-expr) be supported though? Yes. That's what I intended, sorry the wording wasn't clear. Please nail it down in the doc so it doesn't get neglected. -- Andrei Reading the DIP again, This adds a pragma 'inline', which is followed by an optional boolean expression, which influences the inlining of the function it appears in. An evaluation of 'true' means always inline, 'false' means never inline, and no argument means the default behavior. Seems clear enough. Also, the Rationale seems outdated now too. Currently: Sometimes generating better code requires runtime profile information. But being a static compiler, not a JIT, the compiler could use such hints from the programmer. I would change that rationale to this one (feel free to confirm and/or copy): Programmers will sometimes want precise control of the compiler's inlining behavior, either to improve performance in debug builds, or to be completely sure that a function is inlined, or to ensure access to the function's runtime profiling information by not inlining it. This DIP addresses those needs. Warning: Careless forcing of inlining can decrease performance dramatically. Use with caution. Also, speaking of hints to the compiler: pragma(hotcodepath, true/false); ... seems really interesting to me, although that's clearly the subject for a different DIP. I just wanted to emphasize that the current DIP is not meant to address that feature. Profile guided optimizations would also be an option I guess. -- Paulo
Re: DIP56 - inlining
On 2015-02-04 21:06, Walter Bright wrote: With -inline: pragma(inline, true) inlines pragma(inline, false) does not inline pragma(inline) inlines at compiler's discretion Without -inline: pragma(inline, true) inlines pragma(inline, false) does not inline pragma(inline) does not inline I see it's in the DIP now, that's great, thanks. -- /Jacob Carlborg
Re: DIP56 - inlining
On 2/4/15 4:08 AM, Walter Bright wrote: On 2/4/2015 3:08 AM, Johannes Pfau wrote: The compiler will still have to generate a complete function which takes up space in the object file. Space in the object file is not important Yah, just within reason etc. etc. -- Andrei
Re: DIP56 - inlining
On 2/4/15 4:02 AM, Walter Bright wrote: On 2/4/2015 1:39 AM, ponce wrote: Would pragma(inline, bool-expr) be supported though? Yes. That's what I intended, sorry the wording wasn't clear. Please nail it down in the doc so it doesn't get neglected. -- Andrei
Re: DIP56 - inlining
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP56 There's been enough discussion, time to make a decision and move on. I changed the description to: If a pragma specifies always inline, and the compiler cannot inline it, a warning will be generated. Implementations will likely vary in their ability to inline. I like it. This feels better than the C++ force_inline attribute solution. Would pragma(inline, bool-expr) be supported though? This would allow to pass inlining as a template parameter (can be useful to force recursive inlining, or to force inlining depending on the call point).
Re: DIP56 - inlining
On Wednesday, 4 February 2015 at 07:16:03 UTC, ketmar wrote: On Wed, 04 Feb 2015 06:59:52 +, Ola Fosheim Grøstad wrote: On Wednesday, 4 February 2015 at 05:20:30 UTC, ketmar wrote: as for uglyness... it's too late to thing about this. one more, one less... ;-) Wait... That used to be told about C++, not about D...
Re: DIP56 - inlining
On 4 February 2015 at 07:16, ketmar via Digitalmars-d digitalmars-d@puremagic.com wrote: On Wed, 04 Feb 2015 06:59:52 +, Ola Fosheim Grøstad wrote: On Wednesday, 4 February 2015 at 05:20:30 UTC, ketmar wrote: there. i still can't see what's wrong with `@attribute(inline)`, `@attribute(force_inline)` and so on. ah, except it breaks one of the first rules in The Book Of D: try to escape uniformity whenever it is possible. Using pragmas for inlining is common in compilers for other clean languages (Ada, Haskell). Unless inlining affects the ability to use functions as actual parameters it is not part of the language and therefore a pragma, but I agree that the pragma syntax is ugly, but @attribute is also ugly. Maybe better to reserve @_word so that they cannot be used for UDA and let all pragmas start with @_: @_inline(0) // never, inline_weight*0 = 0 @_inline(1) // default, inline_weight*1 = inline_weight @_inline(Inf) // always, inline_weight*Inf = Inf @_inline // same as @_inline(Inf) using `@attribute(...)` is ugly, but it has the advantage of simple workarounding for compilers that still not supporting that attribute. You can tell the compiler to ignore unknown pragmas too...
Re: DIP56 - inlining
On Wednesday, February 04, 2015 09:07:12 ketmar via Digitalmars-d wrote: D is in the same position now. that ship is sailed, we don't break the code, happy legacy, folks! Not quite. The C++ folks basically won't break backwards compatibility for anything. There are a few rare cases in the recent standards where they deprecated something that was just outright a bad idea and that no one sensible was using better anyway (e.g. non-empty throw specifiers). With D, we're reaching the point where we don't want to break backwards compatability if we can avoid it, and the bar for doing so is relatively high, but we'll still do it if we deem that the cost is worth gain (though part of the problem is how subjective that can be). So, we're not as rigid as C++ is, but we _are_ past the point where we purposefully make breaking changes on a regular basis (though unfortunately, regressions get through with pretty much every release). So, anyone looking for a particularly malleable language is going to be unhappy with D, but unlike C++, it's not set in stone. - Jonathan M Davis
Re: DIP56 - inlining
On Wed, 04 Feb 2015 08:06:06 +, eles wrote: On Wednesday, 4 February 2015 at 07:16:03 UTC, ketmar wrote: On Wed, 04 Feb 2015 06:59:52 +, Ola Fosheim Grøstad wrote: On Wednesday, 4 February 2015 at 05:20:30 UTC, ketmar wrote: as for uglyness... it's too late to thing about this. one more, one less... ;-) Wait... That used to be told about C++, not about D... D is in the same position now. that ship is sailed, we don't break the code, happy legacy, folks! signature.asc Description: PGP signature
Re: DIP56 - inlining
On Wed, 04 Feb 2015 08:11:40 +, Iain Buclaw via Digitalmars-d wrote: You can tell the compiler to ignore unknown pragmas too... `@attribute(...)` has another advantage: it's already working at least in one compiler. whereas proposed `pragma` is not working yet. ;-) signature.asc Description: PGP signature
Re: DIP56 - inlining
On 2015-02-03 23:29, Walter Bright wrote: http://wiki.dlang.org/DIP56 There's been enough discussion, time to make a decision and move on. This is affected by the -inline flag? -- /Jacob Carlborg
Re: DIP56 - inlining
On Wednesday, 4 February 2015 at 18:00:19 UTC, Jacob Carlborg wrote: On 2015-02-03 23:29, Walter Bright wrote: http://wiki.dlang.org/DIP56 There's been enough discussion, time to make a decision and move on. This is affected by the -inline flag? Interesting question. I'd say without -inline we don't perform an inline pass so nothing gets inline.
Re: DIP56 - inlining
On 2/4/2015 8:29 AM, Andrei Alexandrescu wrote: On 2/4/15 4:02 AM, Walter Bright wrote: On 2/4/2015 1:39 AM, ponce wrote: Would pragma(inline, bool-expr) be supported though? Yes. That's what I intended, sorry the wording wasn't clear. Please nail it down in the doc so it doesn't get neglected. -- Andrei Reading the DIP again, This adds a pragma 'inline', which is followed by an optional boolean expression, which influences the inlining of the function it appears in. An evaluation of 'true' means always inline, 'false' means never inline, and no argument means the default behavior. Seems clear enough.
Re: DIP56 - inlining
On 2/4/2015 10:00 AM, Jacob Carlborg wrote: On 2015-02-03 23:29, Walter Bright wrote: http://wiki.dlang.org/DIP56 There's been enough discussion, time to make a decision and move on. This is affected by the -inline flag? With -inline: pragma(inline, true) inlines pragma(inline, false) does not inline pragma(inline) inlines at compiler's discretion Without -inline: pragma(inline, true) inlines pragma(inline, false) does not inline pragma(inline) does not inline
Re: DIP56 - inlining
On Wednesday, 4 February 2015 at 20:09:04 UTC, Walter Bright wrote: On 2/4/2015 8:29 AM, Andrei Alexandrescu wrote: On 2/4/15 4:02 AM, Walter Bright wrote: On 2/4/2015 1:39 AM, ponce wrote: Would pragma(inline, bool-expr) be supported though? Yes. That's what I intended, sorry the wording wasn't clear. Please nail it down in the doc so it doesn't get neglected. -- Andrei Reading the DIP again, This adds a pragma 'inline', which is followed by an optional boolean expression, which influences the inlining of the function it appears in. An evaluation of 'true' means always inline, 'false' means never inline, and no argument means the default behavior. Seems clear enough. That was me, based on what you had posted. I will now add ... default behavior, as indicated in the command line.
Re: DIP56 - inlining
On Wednesday, 4 February 2015 at 20:09:04 UTC, Walter Bright wrote: On 2/4/2015 8:29 AM, Andrei Alexandrescu wrote: On 2/4/15 4:02 AM, Walter Bright wrote: On 2/4/2015 1:39 AM, ponce wrote: Would pragma(inline, bool-expr) be supported though? Yes. That's what I intended, sorry the wording wasn't clear. Please nail it down in the doc so it doesn't get neglected. -- Andrei Reading the DIP again, This adds a pragma 'inline', which is followed by an optional boolean expression, which influences the inlining of the function it appears in. An evaluation of 'true' means always inline, 'false' means never inline, and no argument means the default behavior. Seems clear enough. Also, the Rationale seems outdated now too. Currently: Sometimes generating better code requires runtime profile information. But being a static compiler, not a JIT, the compiler could use such hints from the programmer. I would change that rationale to this one (feel free to confirm and/or copy): Programmers will sometimes want precise control of the compiler's inlining behavior, either to improve performance in debug builds, or to be completely sure that a function is inlined, or to ensure access to the function's runtime profiling information by not inlining it. This DIP addresses those needs. Warning: Careless forcing of inlining can decrease performance dramatically. Use with caution. Also, speaking of hints to the compiler: pragma(hotcodepath, true/false); ... seems really interesting to me, although that's clearly the subject for a different DIP. I just wanted to emphasize that the current DIP is not meant to address that feature.
Re: DIP56 - inlining
On 2/4/15 12:08 PM, Walter Bright wrote: On 2/4/2015 8:29 AM, Andrei Alexandrescu wrote: On 2/4/15 4:02 AM, Walter Bright wrote: On 2/4/2015 1:39 AM, ponce wrote: Would pragma(inline, bool-expr) be supported though? Yes. That's what I intended, sorry the wording wasn't clear. Please nail it down in the doc so it doesn't get neglected. -- Andrei Reading the DIP again, This adds a pragma 'inline', which is followed by an optional boolean expression, which influences the inlining of the function it appears in. An evaluation of 'true' means always inline, 'false' means never inline, and no argument means the default behavior. Seems clear enough. I have preliminarily approved http://wiki.dlang.org/DIP56 for post 2.067. -- Andrei
Re: DIP56 - inlining
On Wednesday, 4 February 2015 at 20:09:04 UTC, Walter Bright wrote: On 2/4/2015 8:29 AM, Andrei Alexandrescu wrote: On 2/4/15 4:02 AM, Walter Bright wrote: On 2/4/2015 1:39 AM, ponce wrote: Would pragma(inline, bool-expr) be supported though? Yes. That's what I intended, sorry the wording wasn't clear. Please nail it down in the doc so it doesn't get neglected. -- Andrei Reading the DIP again, This adds a pragma 'inline', which is followed by an optional boolean expression, which influences the inlining of the function it appears in. An evaluation of 'true' means always inline, 'false' means never inline, and no argument means the default behavior. Seems clear enough. It just occurred to me, you might to take an small integer as the second parameter, so people can customize their whole builds: enum useDefaultInline = 0; enum useProfilingInline = 1; enum forceInlines = 2; enum inlineStrategy = forceInlines; // change this at will pragma(inline, inlineStrategy); // now you can get always, never, or default as you choose With only a bool as the second parameter, you couldn't do this.
Re: DIP56 - inlining
On Wednesday, 4 February 2015 at 10:57:25 UTC, Johannes Pfau
wrote:
That's not necessary. For GDC you can do this:
alias forceinline = Attribute!(forceinline);
(I don't remember the exact syntax but you can use an alias)
Then you can simply do
@forceinline void test (){};
Yes, your attribute syntax is quite ok, but if the outcome is
that each program is having their own inline syntax then it is
less than satisfactory.
Re: DIP56 - inlining
On Wednesday, 4 February 2015 at 08:06:08 UTC, eles wrote: On Wednesday, 4 February 2015 at 07:16:03 UTC, ketmar wrote: On Wed, 04 Feb 2015 06:59:52 +, Ola Fosheim Grøstad wrote: On Wednesday, 4 February 2015 at 05:20:30 UTC, ketmar wrote: as for uglyness... it's too late to thing about this. one more, one less... ;-) Wait... That used to be told about C++, not about D... :-D John Nagle on Rust: «I'm concerned that Rust is starting out at the cruft level it took C++ 20 years to achieve. I shudder to think of what things will be like once the Boost crowd discovers Rust.» http://lambda-the-ultimate.org/node/5113 Seems like the C++ replacement languages have problems reaching a stable release without aggregating cruft...
Re: DIP56 - inlining
Am Tue, 03 Feb 2015 14:29:59 -0800 schrieb Walter Bright newshou...@digitalmars.com: http://wiki.dlang.org/DIP56 There's been enough discussion, time to make a decision and move on. I changed the description to: If a pragma specifies always inline, and the compiler cannot inline it, a warning will be generated. Implementations will likely vary in their ability to inline. One thing this DIP should clearly state is whether a pragma(inline, true) functions must still have a valid address. The answer is probably yes as this is how C compilers handle inline. This however makes pragma(inline, true) functions less useful as replacements for C macros: The compiler will still have to generate a complete function which takes up space in the object file. The reasoning why it can't be an attribute is kinda flawed. People want this to be an compiler recognized UDA like in GDC (1), not a normal attribute. UDAs never affect the function signature. (1) https://github.com/D-Programming-GDC/GDC/blob/master/libphobos/libdruntime/gcc/attribute.d
Re: DIP56 - inlining
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP56 There's been enough discussion, time to make a decision and move on. Great, gets the job done and you even thought of on/off/default to apply this to multiple functions. It provides the common inline hint semantics, so it should be easy to support across all compilers.
Re: DIP56 - inlining
On 2/4/2015 4:08 AM, Walter Bright wrote: On 2/4/2015 3:08 AM, Johannes Pfau wrote: The compiler will still have to generate a complete function which takes up space in the object file. Space in the object file is not important, space in the executable is. It's the linker's job to remove unreferenced functions (dmd places each function in its own section for that and other reasons). If the linker falls down on that job, an alternative is to use dmd to generate a library, where it will generate one object in the library per function. Then, the linker will only pull objects out of the library that are actually referenced. Forgot to mention, you could also use string mixins.
Re: DIP56 - inlining
On Wednesday, 4 February 2015 at 10:57:25 UTC, Johannes Pfau
wrote:
alias forceinline = Attribute!(forceinline);
(I don't remember the exact syntax but you can use an alias)
The syntax I'm using is...
version (GNU)
{
static import gcc.attribute;
enum inline = gcc.attribute.attribute(forceinline);
}
@inline T volatileLoad(T)(T* a)
{
asm { ::: memory; };
return *cast(shared T*)a;
}
@inline void volatileStore(T)(T* a, in T v)
{
asm { ::: memory; };
*cast(shared T*)a = v;
}
Quite nice IMO.
Mike
Re: DIP56 - inlining
On 2/4/2015 1:39 AM, ponce wrote: Would pragma(inline, bool-expr) be supported though? Yes. That's what I intended, sorry the wording wasn't clear.
Re: DIP56 - inlining
Am Wed, 04 Feb 2015 06:59:52 +
schrieb Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com:
but I agree that the pragma syntax is ugly, but @attribute is
also ugly.
Maybe better to reserve @_word so that they cannot be used for
UDA and let all pragmas start with @_:
That's not necessary. For GDC you can do this:
alias forceinline = Attribute!(forceinline);
(I don't remember the exact syntax but you can use an alias)
Then you can simply do
@forceinline void test (){};
There's no need to reserve @_ as UDAs follow normal lookup rules.
@forceinline consflicts with some other UDA? Than use the full name,
renamed imports, add an alias, ...
That's a huge benefit of UDAs.
Re: DIP56 - inlining
On 2/4/2015 3:08 AM, Johannes Pfau wrote: The compiler will still have to generate a complete function which takes up space in the object file. Space in the object file is not important, space in the executable is. It's the linker's job to remove unreferenced functions (dmd places each function in its own section for that and other reasons). If the linker falls down on that job, an alternative is to use dmd to generate a library, where it will generate one object in the library per function. Then, the linker will only pull objects out of the library that are actually referenced.
Re: DIP56 - inlining
On Wednesday, 4 February 2015 at 12:02:32 UTC, Walter Bright wrote: On 2/4/2015 1:39 AM, ponce wrote: Would pragma(inline, bool-expr) be supported though? Yes. That's what I intended, sorry the wording wasn't clear. As long as you're sure the pragma will never need more than three values ([revert to default], true, and false).
Re: DIP56 - inlining
Am Wed, 04 Feb 2015 04:11:22 -0800 schrieb Walter Bright newshou...@digitalmars.com: On 2/4/2015 4:08 AM, Walter Bright wrote: On 2/4/2015 3:08 AM, Johannes Pfau wrote: The compiler will still have to generate a complete function which takes up space in the object file. Space in the object file is not important, space in the executable is. It's the linker's job to remove unreferenced functions (dmd places each function in its own section for that and other reasons). If the linker falls down on that job, an alternative is to use dmd to generate a library, where it will generate one object in the library per function. Then, the linker will only pull objects out of the library that are actually referenced. Forgot to mention, you could also use string mixins. OK, I just said the DIP should make that clear. I'm not going to discuss this any further it's just wasted time.
Re: DIP56 - inlining
Am Wed, 04 Feb 2015 12:47:24 +
schrieb Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com:
On Wednesday, 4 February 2015 at 10:57:25 UTC, Johannes Pfau
wrote:
That's not necessary. For GDC you can do this:
alias forceinline = Attribute!(forceinline);
(I don't remember the exact syntax but you can use an alias)
Then you can simply do
@forceinline void test (){};
Yes, your attribute syntax is quite ok, but if the outcome is
that each program is having their own inline syntax then it is
less than satisfactory.
obviously the alias could also be standardized and placed into
gcc.attribute...
Re: DIP56 - inlining
On Wednesday, 4 February 2015 at 09:39:56 UTC, ponce wrote: Would pragma(inline, bool-expr) be supported though? This would allow to pass inlining as a template parameter (can be useful to force recursive inlining, or to force inlining depending on the call point). Nice idea.
Re: DIP56 - inlining
On 04.02.15 07:46, Zach the Mystic wrote: It's a bikeshed argument, but why not: pragma(inline, always); // warn if unable to inline pragma(inline, never); pragma(inline);// revert to default behavior ...? I know `true` and `false` are keywords, but why confuse people? What is a true inline? I don't think it's about confusion or aesthetic. For me it's about flexibility and evolution. pragma(inline, always); pragma(inline, never); You can easily add new meaning. pragma(inline, whatever); There are maybe some potential here, why to preclude.
Re: DIP56 - inlining
On 2/4/2015 12:46 PM, Zach the Mystic wrote: On Wednesday, 4 February 2015 at 20:09:04 UTC, Walter Bright wrote: On 2/4/2015 8:29 AM, Andrei Alexandrescu wrote: On 2/4/15 4:02 AM, Walter Bright wrote: On 2/4/2015 1:39 AM, ponce wrote: Would pragma(inline, bool-expr) be supported though? Yes. That's what I intended, sorry the wording wasn't clear. Please nail it down in the doc so it doesn't get neglected. -- Andrei Reading the DIP again, This adds a pragma 'inline', which is followed by an optional boolean expression, which influences the inlining of the function it appears in. An evaluation of 'true' means always inline, 'false' means never inline, and no argument means the default behavior. Seems clear enough. That was me, based on what you had posted. I will now add ... default behavior, as indicated in the command line. Thanks.
Re: DIP56 - inlining
On Wednesday, 4 February 2015 at 02:44:46 UTC, Mike wrote: This is not what I want either. I find @always_inline and @never_inline attributes with compile-time enforcement *far* more useful. pragma(inline, true) will not compile if you enabled warnings as errors.
Re: DIP56 - inlining
On 2/3/2015 4:24 PM, Mike wrote: ...it should read... pragma(inline, true); // enable -inline compiler flag pragma(inline, false); // disable -inline compiler flag pragma(inline);// use whatever is passed in on the command line ...as that is really the intent of DIP56 as confirmed by Walter [1]. Well, perhaps I worded that poorly. The compiler has a 'cost' function it uses to decide whether to inline or not. The pragma will cause it to ignore the cost function and always inline it.
Re: DIP56 - inlining
On Tue, 03 Feb 2015 23:37:58 +, Justin Whear wrote:
On Tue, 03 Feb 2015 23:34:15 +, an wrote:
Pragmas can be used as attribute that doesn't affect the semantics.
This syntax is not supported in this DIP?
pragma(inline, true)
{
void foo() { }
void bar() { }
}
I assume it's covered by If this pragma is outside of a function, it
affects the functions in the block it encloses.
and so it's completely unusable on module level, as {} is not allowed
there. i still can't see what's wrong with `@attribute(inline)`,
`@attribute(force_inline)` and so on. ah, except it breaks one of the
first rules in The Book Of D: try to escape uniformity whenever it is
possible.
signature.asc
Description: PGP signature
Re: DIP56 - inlining
On Wednesday, 4 February 2015 at 05:17:11 UTC, ketmar wrote: On Tue, 03 Feb 2015 22:47:30 +, Orvid King wrote: On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP56 There's been enough discussion, time to make a decision and move on. I changed the description to: If a pragma specifies always inline, and the compiler cannot inline it, a warning will be generated. Implementations will likely vary in their ability to inline. I just created a proposal for a more general syntax to allow user's to apply attributes like inlining in a way that can easily be supported across compilers, and, in my eyes, is clearer about what code the attribute is applied to than a pragma is. http://wiki.dlang.org/DIP72 gcc using `@attribute(name)` for this. it's easier and requires no compiler hacks to ignore. Yes, but @attribute isn't defined when compiling with DMD, resulting in the need for some fun with version statements. My proposal was to add a mechanism in the frontend to recognize it. @attribute also has the limitation of it being a UDA, so it can't be used for things like branch hinting. I meant to include it in DIP 72, but forgot about that aspect of it; but I'd hope with DIP 72 to be able to allow @compiler attributes on statements, and, potentially, on expressions as well.
Re: DIP56 - inlining
Will this proposal allow to override the inlining of a function at the call site?
Re: DIP56 - inlining
On 2/3/2015 9:00 PM, Mike wrote: On Wednesday, 4 February 2015 at 04:46:41 UTC, Walter Bright wrote: The pragma will cause it to ignore the cost function and always inline it. So, if pragma(inline, true) ignores the cost function, will it *always* inline it, or always apply the -inline compiler flag rules (whatever they are)? If the former, Yes. then I have misunderstood DIP56 yet again. If the latter, then yes, it could have been worded better. Entirely my fault. Sorry about the confusion.
Re: DIP56 - inlining
On Wednesday, 4 February 2015 at 05:03:03 UTC, Walter Bright wrote: So, if pragma(inline, true) ignores the cost function, will it *always* inline it, or always apply the -inline compiler flag rules (whatever they are)? If the former, Yes. Ok, then please ignore all my posts on this topic if you aren't already. Mike
Re: DIP56 - inlining
On Wednesday, 4 February 2015 at 04:46:41 UTC, Walter Bright wrote: The pragma will cause it to ignore the cost function and always inline it. So, if pragma(inline, true) ignores the cost function, will it *always* inline it, or always apply the -inline compiler flag rules (whatever they are)? If the former, then I have misunderstood DIP56 yet again. If the latter, then yes, it could have been worded better. Mike
Re: DIP56 - inlining
On Wednesday, 4 February 2015 at 02:52:07 UTC, Andrei Alexandrescu wrote: The question is, can you get work done with the currently proposed semantics? If so, let's commit to this and move on. Yes, I may be able to make use of it on occasion, but only because other, more useful features are not implemented. Mike
Re: DIP56 - inlining
On Wednesday, 4 February 2015 at 03:59:08 UTC, Meta wrote: pragma(inline, true) will not compile if you enabled warnings as errors. I know, but this is the mediocrity I'm talking about: it only works as one wishes/expects under certain conditions. Mike
Re: DIP56 - inlining
On 2/3/2015 5:57 PM, ZombineDev wrote: Will this proposal allow to override the inlining of a function at the call site? No. It marks the function, not the call site. Though there would a simple way to do this - make a 'never inline' function that wraps the 'always inline' one, and call the former.
Re: DIP56 - inlining
On Tue, 03 Feb 2015 22:47:30 +, Orvid King wrote: On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP56 There's been enough discussion, time to make a decision and move on. I changed the description to: If a pragma specifies always inline, and the compiler cannot inline it, a warning will be generated. Implementations will likely vary in their ability to inline. I just created a proposal for a more general syntax to allow user's to apply attributes like inlining in a way that can easily be supported across compilers, and, in my eyes, is clearer about what code the attribute is applied to than a pragma is. http://wiki.dlang.org/DIP72 gcc using `@attribute(name)` for this. it's easier and requires no compiler hacks to ignore. signature.asc Description: PGP signature
Re: DIP56 - inlining
On Wed, 04 Feb 2015 05:24:18 +, Orvid King wrote:
Yes, but @attribute isn't defined when compiling with DMD, resulting in
the need for some fun with version statements.
exactly one module, say, for example, `gcccompat.d`:
module gcccompat;
version(GNU) {
public import gcc.attribute;
} else {
private struct Attribute(A...) { A args; }
auto attribute(A...) (A args)
if (A.length 0 is(A[0] == string))
{ return Attribute!A(args); }
}
@attribute(forceinline) int test () { return 42; }
// wow, this works in DMD and LDC!
that's it. only one module, which can be easily added to any project. no
need to modify the compiler in any way.
@attribute also has the
limitation of it being a UDA, so it can't be used for things like branch
hinting.
how `@compiler(inline, never)` can be used for branch hinting? oh, on the
second thought i don't want to see that syntax.
I meant to include it in DIP 72, but forgot about that aspect
of it; but I'd hope with DIP 72 to be able to allow @compiler attributes
on statements, and, potentially, on expressions as well.
it still looks like UDA, it *can* be completely substituted by one UDA
with string arguments, it adds hacks and special rules to the compiler.
no wander Walter says no for it.
signature.asc
Description: PGP signature
Re: DIP56 - inlining
On Wednesday, 4 February 2015 at 04:11:39 UTC, Mike wrote: On Wednesday, 4 February 2015 at 03:59:08 UTC, Meta wrote: pragma(inline, true) will not compile if you enabled warnings as errors. I know, but this is the mediocrity I'm talking about: it only works as one wishes/expects under certain conditions. Allow me to elaborate as that sounds awfully whiny. The original DIP56 was actually ok because it left open the chance of implementing some kind of @always_inline/@never_inline with compile-time enforcement. It was just worded poorly, so everyone appeared to think is was being proposed as half-implemented. However, now with this latest proposal, it will always be used as an excuse for not implementing @always_inline/@never_inline with compile-time enforcement. So, yes, we are better off than we are now with this proposal, but we lose the chance of being great. Mike
Re: DIP56 - inlining
On Wednesday, 4 February 2015 at 00:39:05 UTC, Dicebot wrote: pragma(inline, true); // enable -inline compiler flag pragma(inline, false); // disable -inline compiler flag pragma(inline);// use whatever is passed in on the command line ...as that is really the intent of DIP56 as confirmed by Walter. No this is definitely not what I wanted. This is not what I want either. I find @always_inline and @never_inline attributes with compile-time enforcement *far* more useful. But DIP56 was not originally intended to address that need, and it's a shame it was worded as if it was. pragma(inline, true) is not always inline and pragma(inline, false) is not never inline. Implementing DIP56 as it was originally intended (or more intuitively as a way to add compiler flags to part of a file) would not prevent the addition of future features to enable inlining enforcement. But now we're compromising to mediocrity where noone really wins. Mike
Re: DIP56 - inlining
On 2/3/15 6:44 PM, Mike wrote: On Wednesday, 4 February 2015 at 00:39:05 UTC, Dicebot wrote: pragma(inline, true); // enable -inline compiler flag pragma(inline, false); // disable -inline compiler flag pragma(inline);// use whatever is passed in on the command line ...as that is really the intent of DIP56 as confirmed by Walter. No this is definitely not what I wanted. This is not what I want either. I find @always_inline and @never_inline attributes with compile-time enforcement *far* more useful. But DIP56 was not originally intended to address that need, and it's a shame it was worded as if it was. pragma(inline, true) is not always inline and pragma(inline, false) is not never inline. Implementing DIP56 as it was originally intended (or more intuitively as a way to add compiler flags to part of a file) would not prevent the addition of future features to enable inlining enforcement. But now we're compromising to mediocrity where noone really wins. Nobody really loses, either. (I'll note that gcc has several mechanisms for enabling/disabling inlining, all of which issue a warning at the most.) The question is, can you get work done with the currently proposed semantics? If so, let's commit to this and move on. Andrei
Re: DIP56 - inlining
On Wed, 04 Feb 2015 07:26:04 +, Ola Fosheim Grøstad wrote: On Wednesday, 4 February 2015 at 07:16:03 UTC, ketmar wrote: as for uglyness... it's too late to thing about this. one more, one less... ;-) Are you following the reasoning: the uglier the better, because that will set us up for a clean slate syntax redesign? :) don't tell it anyone, it's a *secret* plan after all! signature.asc Description: PGP signature
Re: DIP56 - inlining
On Wednesday, 4 February 2015 at 05:20:30 UTC, ketmar wrote: there. i still can't see what's wrong with `@attribute(inline)`, `@attribute(force_inline)` and so on. ah, except it breaks one of the first rules in The Book Of D: try to escape uniformity whenever it is possible. Using pragmas for inlining is common in compilers for other clean languages (Ada, Haskell). Unless inlining affects the ability to use functions as actual parameters it is not part of the language and therefore a pragma, but I agree that the pragma syntax is ugly, but @attribute is also ugly. Maybe better to reserve @_word so that they cannot be used for UDA and let all pragmas start with @_: @_inline(0) // never, inline_weight*0 = 0 @_inline(1) // default, inline_weight*1 = inline_weight @_inline(Inf) // always, inline_weight*Inf = Inf @_inline // same as @_inline(Inf)
Re: DIP56 - inlining
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP56 There's been enough discussion, time to make a decision and move on. I changed the description to: If a pragma specifies always inline, and the compiler cannot inline it, a warning will be generated. Implementations will likely vary in their ability to inline. It's a bikeshed argument, but why not: pragma(inline, always); // warn if unable to inline pragma(inline, never); pragma(inline);// revert to default behavior ...? I know `true` and `false` are keywords, but why confuse people? What is a true inline?
Re: DIP56 - inlining
On Wed, 04 Feb 2015 06:59:52 +, Ola Fosheim Grøstad wrote:
On Wednesday, 4 February 2015 at 05:20:30 UTC, ketmar wrote:
there. i still can't see what's wrong with `@attribute(inline)`,
`@attribute(force_inline)` and so on. ah, except it breaks one of the
first rules in The Book Of D: try to escape uniformity whenever it is
possible.
Using pragmas for inlining is common in compilers for other clean
languages (Ada, Haskell).
Unless inlining affects the ability to use functions as actual
parameters it is not part of the language and therefore a pragma,
but I agree that the pragma syntax is ugly, but @attribute is also
ugly.
Maybe better to reserve @_word so that they cannot be used for UDA and
let all pragmas start with @_:
@_inline(0) // never, inline_weight*0 = 0 @_inline(1) // default,
inline_weight*1 = inline_weight @_inline(Inf) // always,
inline_weight*Inf = Inf @_inline // same as @_inline(Inf)
using `@attribute(...)` is ugly, but it has the advantage of simple
workarounding for compilers that still not supporting that attribute.
plus, it allows things like `@attribute(...) { ... }` or `@attribute
(...):` on module level, whereas `pragma` isn't.
as for uglyness... it's too late to thing about this. one more, one
less... ;-)
signature.asc
Description: PGP signature
Re: DIP56 - inlining
On Wednesday, 4 February 2015 at 07:16:03 UTC, ketmar wrote: as for uglyness... it's too late to thing about this. one more, one less... ;-) Are you following the reasoning: the uglier the better, because that will set us up for a clean slate syntax redesign? :)
Re: DIP56 - inlining
On Tuesday, 3 February 2015 at 23:23:35 UTC, deadalnix wrote: We have an attribute system, why make this a pragma ? Rationale is in the DIP: These are not attributes because they should not affect the semantics of the function. In particular, the function signature must not be affected.
Re: DIP56 - inlining
On Tue, 03 Feb 2015 23:34:15 +, an wrote:
Pragmas can be used as attribute that doesn't affect the semantics. This
syntax is not supported in this DIP?
pragma(inline, true)
{
void foo() { }
void bar() { }
}
I assume it's covered by If this pragma is outside of a function, it
affects the functions in the block it encloses.
Re: DIP56 - inlining
On Tuesday, 3 February 2015 at 23:25:26 UTC, Peter Alexander wrote: On Tuesday, 3 February 2015 at 23:23:35 UTC, deadalnix wrote: We have an attribute system, why make this a pragma ? Rationale is in the DIP: These are not attributes because they should not affect the semantics of the function. In particular, the function signature must not be affected. That's bullshit. UDA do not change the semantic of a function. By the same reasoning they should be user defined pragma ?!??
DIP56 - inlining
http://wiki.dlang.org/DIP56 There's been enough discussion, time to make a decision and move on. I changed the description to: If a pragma specifies always inline, and the compiler cannot inline it, a warning will be generated. Implementations will likely vary in their ability to inline.
Re: DIP56 - inlining
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP56 There's been enough discussion, time to make a decision and move on. I changed the description to: If a pragma specifies always inline, and the compiler cannot inline it, a warning will be generated. Implementations will likely vary in their ability to inline. We have an attribute system, why make this a pragma ? Also, this is going to be a challenge to detect if something have been inlined unless inlining is done in the frontend.
Re: DIP56 - inlining
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote: There's been enough discussion, time to make a decision and move on. I'm glad this is being said more and more around these parts. Some stuff just seems to be stagnating forever.
Re: DIP56 - inlining
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP56 There's been enough discussion, time to make a decision and move on. I changed the description to: If a pragma specifies always inline, and the compiler cannot inline it, a warning will be generated. Implementations will likely vary in their ability to inline. I just created a proposal for a more general syntax to allow user's to apply attributes like inlining in a way that can easily be supported across compilers, and, in my eyes, is clearer about what code the attribute is applied to than a pragma is. http://wiki.dlang.org/DIP72
Re: DIP56 - inlining
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP56
There's been enough discussion, time to make a decision and
move on.
I changed the description to:
If a pragma specifies always inline, and the compiler cannot
inline it, a warning will be generated. Implementations will
likely vary in their ability to inline.
Pragmas can be used as attribute that doesn't affect the
semantics. This syntax is not supported in this DIP?
pragma(inline, true)
{
void foo() { }
void bar() { }
}
Re: DIP56 - inlining
On 2/3/2015 2:47 PM, Orvid King wrote: I just created a proposal for a more general syntax to allow user's to apply attributes like inlining in a way that can easily be supported across compilers, and, in my eyes, is clearer about what code the attribute is applied to than a pragma is. http://wiki.dlang.org/DIP72 I appreciate that you took the time to create a proposal, but no. Please, let's move on.
Re: DIP56 - inlining
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP56 There's been enough discussion, time to make a decision and move on. I changed the description to: If a pragma specifies always inline, and the compiler cannot inline it, a warning will be generated. Implementations will likely vary in their ability to inline. I think this whole debate could have been avoided if the DIP was worded differently. Instead of... pragma(inline, true); // always inline pragma(inline, false); // never inline pragma(inline);// revert to default behavior ...it should read... pragma(inline, true); // enable -inline compiler flag pragma(inline, false); // disable -inline compiler flag pragma(inline);// use whatever is passed in on the command line ...as that is really the intent of DIP56 as confirmed by Walter [1]. Now the problem with this is it is DMD specific, as the compiler flags vary greatly between compilers. So instead it may be better to generalize it. pragma(compile, inline, true) // enable -inline compiler flag pragma(compile, inline, false) // disable -inline compiler flag pragma(compile, inline) // use whatever is passed in on the command line Since GDC doesn't have an -inline flag, it may instead choose to use any or all of the following... pragma(compile, finline-small-functions, true|false) pragma(compile, fno-inline, true|false) pragma(compile, finline-functions, true|false) ... or choose not to implement it a all since it already has `@attribute` mappings to GCC's `__attribute__` syntax [4]. Only the GDC developers can say whether this is feasible or not, but it matches much better to the intent of DIP56 [2]. Perhaps this is more along the lines of what DIP72 [3] is trying to achieve. Mike [1] - Walter confirming behavior of pragma(inline) - http://forum.dlang.org/post/maq4rp$2f9o$1...@digitalmars.com [2] - DIP56 - http://wiki.dlang.org/DIP56 [3] - DIP72 - http://wiki.dlang.org/DIP72 [4] - GCC's Attribute Syntax - https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html
Re: DIP56 - inlining
On Wednesday, 4 February 2015 at 00:24:25 UTC, Mike wrote: I think this whole debate could have been avoided if the DIP was worded differently. Instead of... pragma(inline, true); // always inline pragma(inline, false); // never inline pragma(inline);// revert to default behavior ...it should read... pragma(inline, true); // enable -inline compiler flag pragma(inline, false); // disable -inline compiler flag pragma(inline);// use whatever is passed in on the command line ...as that is really the intent of DIP56 as confirmed by Walter [1]. No this is definitely not what I wanted. Proposed version with warning sounds like acceptable compromise though.
Re: DIP56 - inlining
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP56 There's been enough discussion, time to make a decision and move on. I changed the description to: If a pragma specifies always inline, and the compiler cannot inline it, a warning will be generated. Implementations will likely vary in their ability to inline. Looks OK. Can't say that I fully understand your reasoning but this should at least be good enough to be practical :)
