On Monday, 24 February 2014 at 22:09:49 UTC, Jerry wrote:
Andrei Alexandrescu writes:
On 2/23/14, 8:26 PM, Vladimir Panteleev wrote:
Thus, I think there should be "try to inline" (same as
-inline) and
"always inline" (failure stops compilation).
Sounds fair enough.
pragma(inline, false);
Andrei Alexandrescu writes:
> On 2/23/14, 8:26 PM, Vladimir Panteleev wrote:
>> Thus, I think there should be "try to inline" (same as -inline) and
>> "always inline" (failure stops compilation).
>
> Sounds fair enough.
pragma(inline, false);
pragma(inline, true);
pragma(inline, force); // inli
On Monday, 24 February 2014 at 16:58:21 UTC, Manu wrote:
For those interested, in my experience, the value of inlining
is rarely
related to eliminating the cost of the function call. call and
ret have
virtually no impact on performance on any architecture I've
used.
It highly depends on the a
On Monday, 24 February 2014 at 18:00:39 UTC, Kapps wrote:
Perhaps something like a -vinline similar to -vtls? You don't
need to be spammed repeatedly every time you build saying
something isn't inlined, yet this still gives an easy way of
seeing which methods you requested to be inlined that were
On Monday, 24 February 2014 at 16:58:21 UTC, Manu wrote:
I agree that inline should be a hint (a STRONG hint, not like
'inline' in
C, more like __force_inline, perhaps stronger), but I'd like it
if I
received a warning when it failed for whatever reason. I don't
want it to
stop compiling, but a
On Monday, 24 February 2014 at 02:05:31 UTC, Walter Bright wrote:
1. It provides information to the compiler about runtime
frequency that it cannot obtain otherwise. This is very useful
information for generating better code.
2. Making it a hard requirement then means the user will have
to
On 24 February 2014 07:53, Walter Bright wrote:
>
> With error - yo get a huge advantage - an _instant_ feedback that it
>> doesn't do
>> what you want it to do. Otherwise it gets the extra pleasure of running
>> disassembler to pinpoint your favorite call sites or observing that your
>> profile
On 23 February 2014 22:55, Walter Bright wrote:
> On 2/23/2014 4:53 AM, ponce wrote:
>
>> On Sunday, 23 February 2014 at 12:07:40 UTC, Walter Bright wrote:
>>
>>> http://wiki.dlang.org/DIP56
>>>
>>> Manu has needed always inlining, and I've needed never inlining. This DIP
>>> proposes a simple so
On 23 February 2014 22:57, Walter Bright wrote:
> On 2/23/2014 4:25 AM, Tove wrote:
>
>> The DIP should probably specify what happens if inlining fails,
>> i.e. generate a compilation error.
>>
>
> I suspect that may cause problems, because different compilers will have
> different inlining capab
On 25 February 2014 02:30, Manu wrote:
> This will probably do, but I still don't understand why not a function
> attribute?
>
Note; GDC and LDC already have inline attributes. It's a pain in the arse
to use them though, since in D, we have no way to alias attributes and
can't do the typical C p
This will probably do, but I still don't understand why not a function
attribute?
Will marking a function as inline notify the compiler that code should
never be emitted to object files for that function?
Perhaps OT:
I've been playing with ranges a lot recently, and std.algorithm and
friends, and
On 2/24/14, 12:55 AM, Walter Bright wrote:
On 2/23/2014 8:18 PM, Andrei Alexandrescu wrote:
On 2/23/14, 6:12 PM, Walter Bright wrote:
On 2/23/2014 5:12 PM, Andrei Alexandrescu wrote:
This makes inlining dependent on previously-seen code. Would that make
parallel
compilation more difficult?
I
On Monday, 24 February 2014 at 02:05:31 UTC, Walter Bright wrote:
pragma(usage, often);
pragma(usage, rare);
This is also useful feature, especially when also applicable to
if branches (I have been using __builtin_expect quite a lot with
GCC). But it is different, I think we need bot
On Monday, 24 February 2014 at 01:09:46 UTC, Araq wrote:
Do you mind to back up your "fact" with some numbers? Afaict
'inline' is more common than __attribute__((forceinline)).
(Well ok for C code #define is even more common, but most C
code is stuck in the 70ies anyway so that doesn't mean
an
On 2/23/2014 8:18 PM, Andrei Alexandrescu wrote:
On 2/23/14, 6:12 PM, Walter Bright wrote:
On 2/23/2014 5:12 PM, Andrei Alexandrescu wrote:
This makes inlining dependent on previously-seen code. Would that make
parallel
compilation more difficult?
I don't understand the question. Inlining alw
On 2/23/2014 6:12 PM, Lionello Lunesu wrote:
On 23/02/14 20:07, Walter Bright wrote:
http://wiki.dlang.org/DIP56
Manu has needed always inlining, and I've needed never inlining. This
DIP proposes a simple solution.
void A()
{
}
void B()
{
pragma(inline, true) A();
No. This would be:
24-Feb-2014 04:33, Walter Bright пишет:
On 2/23/2014 3:55 PM, Mike wrote:
The difference is it was explicitly told do do something and didn't.
That's
insubordination.
I view this as more in the manner of providing the equivalent of runtime
profiling information to the optimizer, in indirectly
24-Feb-2014 03:49, Walter Bright пишет:
On 2/23/2014 3:00 PM, Dmitry Olshansky wrote:
You actually going against yourself with this argument - for porting you
typically suggest:
version(OS1)
...
else version(OS2)
...
else
static assert(0);
There's not much choice about that. I also sugges
On Feb 24, 2014 2:10 AM, "Walter Bright" wrote:
>
> On 2/23/2014 5:45 PM, Brad Roberts wrote:
>>
>> At this point, you're starting to argue that the entire DIP isn't
relevant. I
>> agree with the majority that if you're going to have the directive, then
it
>> needs to be enforcement, not suggesti
On Feb 24, 2014 1:15 AM, "Andrei Alexandrescu" <
seewebsiteforem...@erdani.org> wrote:
>
> On 2/23/14, 4:07 AM, Walter Bright wrote:
>>
>> http://wiki.dlang.org/DIP56
>>
>> Manu has needed always inlining, and I've needed never inlining. This
>> DIP proposes a simple solution.
>
>
> This makes inli
On 2/23/14, 8:26 PM, Vladimir Panteleev wrote:
On Monday, 24 February 2014 at 04:14:08 UTC, Andrei Alexandrescu wrote:
I'll add an anecdote - in HHVM we owe a lot of speedups to the careful
use of "never inline" and "always inline" gcc pragmas IN ADDITION TO
the usual "inline" directives. We hav
On Monday, 24 February 2014 at 02:05:31 UTC, Walter Bright wrote:
1. It provides information to the compiler about runtime
frequency that it cannot obtain otherwise. This is very useful
information for generating better code.
This answers to your own previous question: this is what makes
"inlin
On 2/23/14, 6:05 PM, Walter Bright wrote:
4. I don't see that users really are asking for inlining or not. They
are asking for the fastest code. As such, providing hints about usage
frequencies are entirely appropriate. Micromanaging the method used is
not so appropriate. After all, the reason on
On Monday, 24 February 2014 at 04:14:08 UTC, Andrei Alexandrescu
wrote:
I'll add an anecdote - in HHVM we owe a lot of speedups to the
careful use of "never inline" and "always inline" gcc pragmas
IN ADDITION TO the usual "inline" directives. We have factual
proof that gcc makes the wrong inlin
On 2/23/14, 5:55 PM, bearophile wrote:
Andrei Alexandrescu:
I've always thought the obvious/simple way would be an attribute such
as @forceinline and @noinline that applies to individual functions.
Seems good. And what do you think the D compiler should do when you use
@forceinline and it can
On 2/23/14, 6:12 PM, Walter Bright wrote:
On 2/23/2014 5:12 PM, Andrei Alexandrescu wrote:
This makes inlining dependent on previously-seen code. Would that make
parallel
compilation more difficult?
I don't understand the question. Inlining always depends on the compiler
having seen the functi
On 2/23/14, 4:33 PM, Walter Bright wrote:
On 2/23/2014 3:55 PM, Mike wrote:
The difference is it was explicitly told do do something and didn't.
That's
insubordination.
I view this as more in the manner of providing the equivalent of runtime
profiling information to the optimizer, in indirectl
On Sun, 23 Feb 2014 21:05:32 -0500, Walter Bright
wrote:
On 2/23/2014 5:45 PM, Brad Roberts wrote:
At this point, you're starting to argue that the entire DIP isn't
relevant. I
agree with the majority that if you're going to have the directive,
then it
needs to be enforcement, not sugge
On 23/02/14 20:07, Walter Bright wrote:
http://wiki.dlang.org/DIP56
Manu has needed always inlining, and I've needed never inlining. This
DIP proposes a simple solution.
void A()
{
}
void B()
{
pragma(inline, true) A();
}
void C()
{
B();
}
Reading that code, I would guess that within B(
On 2/23/2014 5:12 PM, Andrei Alexandrescu wrote:
This makes inlining dependent on previously-seen code. Would that make parallel
compilation more difficult?
I don't understand the question. Inlining always depends on the compiler having
seen the function body.
I've always thought the obviou
On 2/23/2014 5:47 PM, Lionello Lunesu wrote:
On 24/02/14 06:12, Walter Bright wrote:
On 2/23/2014 1:41 PM, Namespace wrote:
pragma(inline, true);
pragma(inline, false);
pragma(inline, default);
'default' being a keyword makes for an ugly special case in how pragmas
are parsed.
Aren't true
On 2/23/2014 5:45 PM, Brad Roberts wrote:
At this point, you're starting to argue that the entire DIP isn't relevant. I
agree with the majority that if you're going to have the directive, then it
needs to be enforcement, not suggestion.
1. It provides information to the compiler about runtime
Andrei Alexandrescu:
I've always thought the obvious/simple way would be an
attribute such as @forceinline and @noinline that applies to
individual functions.
Seems good. And what do you think the D compiler should do when
you use @forceinline and it can't inline?
Bye,
bearophile
On 24/02/14 06:12, Walter Bright wrote:
On 2/23/2014 1:41 PM, Namespace wrote:
pragma(inline, true);
pragma(inline, false);
pragma(inline, default);
'default' being a keyword makes for an ugly special case in how pragmas
are parsed.
Aren't true and false keywords as well?
On 2/23/14, 5:05 PM, Walter Bright wrote:
On 2/23/2014 4:21 PM, Tove wrote:
Inspecting asm output doesn't scale well to huge projects. Imagine simply
updating the existing codebase to use a new compiler version.
Again, this is treating 'inline' as being the only optimization that
matters? It's
On Monday, 24 February 2014 at 01:12:56 UTC, Andrei Alexandrescu
wrote:
This makes inlining dependent on previously-seen code. Would
that make parallel compilation more difficult?
I've always thought the obvious/simple way would be an
attribute such as @forceinline and @noinline that applies t
On 2/23/14, 4:07 AM, Walter Bright wrote:
http://wiki.dlang.org/DIP56
Manu has needed always inlining, and I've needed never inlining. This
DIP proposes a simple solution.
This makes inlining dependent on previously-seen code. Would that make
parallel compilation more difficult?
I've always
On 2/23/2014 4:21 PM, Tove wrote:
Inspecting asm output doesn't scale well to huge projects. Imagine simply
updating the existing codebase to use a new compiler version.
Again, this is treating 'inline' as being the only optimization that matters?
It's not even the most important - that would
The fact that original C "inline" was designed in same
"permissive" way and is almost unused in practice (as opposed
to compiler-specific force_inline attributes) does say
something.
Do you mind to back up your "fact" with some numbers? Afaict
'inline' is more common than __attribute__((f
Le 23/02/2014 13:07, Walter Bright a écrit :
http://wiki.dlang.org/DIP56
Manu has needed always inlining, and I've needed never inlining. This
DIP proposes a simple solution.
I saw many times C++ developers works on applications doesn't need such
level optimization puts inline keyword or impl
On Monday, 24 February 2014 at 00:33:09 UTC, Walter Bright wrote:
I suspect that elevating one particular optimization hint to
being an absolute command may not turn out well. Inlining
already has performance issues, as it may increase the size of
an inner loop beyond what will fit in the cache
On 2/23/2014 3:55 PM, Mike wrote:
The difference is it was explicitly told do do something and didn't. That's
insubordination.
I view this as more in the manner of providing the equivalent of runtime
profiling information to the optimizer, in indirectly saying how often a
function is execute
On Sunday, 23 February 2014 at 21:53:43 UTC, Walter Bright wrote:
I'm aware of that, but once you add the:
version(BadCompiler) { } else pragma(inline, true);
things will never get better for BadCompiler. And besides, that
line looks awful.
If I need to support multiple compilers and if
On Sunday, 23 February 2014 at 23:49:57 UTC, Walter Bright wrote:
What makes inlining special, as opposed to, say, enregistering
particular variables?
The difference is it was explicitly told do do something and
didn't. That's insubordination.
Mike
On 2/23/2014 3:00 PM, Dmitry Olshansky wrote:
You actually going against yourself with this argument - for porting you
typically suggest:
version(OS1)
...
else version(OS2)
...
else
static assert(0);
There's not much choice about that. I also suggest moving such code into
separate modules
24-Feb-2014 01:53, Walter Bright пишет:
On 2/23/2014 1:04 PM, Dmitry Olshansky wrote:
That programmer is instantly aware that it can't be done due to some
reason.
Keep in mind that code changes with time and running
profiler/disassembler on
every tiny change to make sure the stuff is still inlin
As a compromise diagnostics about refused inlining can be added
as special output category to
https://github.com/D-Programming-Language/dmd/pull/645
On Sunday, 23 February 2014 at 21:53:43 UTC, Walter Bright wrote:
I'm aware of that, but once you add the:
version(BadCompiler) { } else pragma(inline, true);
things will never get better for BadCompiler.
This is exactly what caused mess with http user agent info when
both browsers tried
On Sunday, 23 February 2014 at 21:55:11 UTC, Walter Bright wrote:
On 2/23/2014 1:32 PM, Francesco Cattoglio wrote:
[...]
I addressed these three messages in another reply to Dmitry.
Read that, and you do make a point. I am no expert on
optimization, but as far as I could tell, inlining is u
On 2/23/2014 1:41 PM, Namespace wrote:
pragma(inline, true);
pragma(inline, false);
pragma(inline, default);
'default' being a keyword makes for an ugly special case in how pragmas are
parsed.
On 2/23/2014 1:53 PM, Walter Bright wrote:
And yes, performance critical code often suffers from bit rot, and changes in
the compiler, and needs to be re-tuned now and then.
BTW, just to reiterate, there are *thousands* of optimizations the compiler may
or may not do. And yes, performance crit
On Sunday, 23 February 2014 at 21:53:43 UTC, Walter Bright wrote:
On 2/23/2014 1:04 PM, Dmitry Olshansky wrote:
That programmer is instantly aware that it can't be done due
to some reason.
Keep in mind that code changes with time and running
profiler/disassembler on
every tiny change to make su
On 2/23/2014 1:32 PM, Francesco Cattoglio wrote:
[...]
I addressed these three messages in another reply to Dmitry.
On Sunday, 23 February 2014 at 21:38:46 UTC, Walter Bright wrote:
On 2/23/2014 12:31 PM, Andrej Mitrovic wrote:
I'd prefer 3 separate states. pragma(inline),
pragma(no_inline), and
pragma(default_inline) or something like that.
That makes documentation with a sorted list of pragmas
impractic
On 2/23/2014 1:04 PM, Dmitry Olshansky wrote:
That programmer is instantly aware that it can't be done due to some reason.
Keep in mind that code changes with time and running profiler/disassembler on
every tiny change to make sure the stuff is still inlined is highly
counter-productive.
I'm aw
On Sunday, 23 February 2014 at 19:10:08 UTC, Namespace wrote:
On Sunday, 23 February 2014 at 12:25:20 UTC, Benjamin Thaut
wrote:
Am 23.02.2014 13:07, schrieb Walter Bright:
http://wiki.dlang.org/DIP56
Manu has needed always inlining, and I've needed never
inlining. This
DIP proposes a simple
On 2/23/2014 12:31 PM, Andrej Mitrovic wrote:
On Sunday, 23 February 2014 at 20:29:19 UTC, Walter Bright wrote:
I'll add:
pragma(inline);
That's just going to confuse people, because they'll think *this* forces
inlining.
Perhaps, but there's precedent with how align works, and how defa
On Sunday, 23 February 2014 at 20:40:44 UTC, Walter Bright wrote:
Generally, when I optimize at that level, I have a window open
on the assembler output of the compiler and I go back and forth
on the source code until I get the shape of the assembler I
need. Having compiler messages wouldn't be
24-Feb-2014 00:40, Walter Bright пишет:
On 2/23/2014 5:01 AM, Vladimir Panteleev wrote:
I think there should be some way to force the compiler to inline a
function. As
a bonus, the error message can tell the programmer why the function
could not be
inlined, allowing them to make the necessary ad
24-Feb-2014 00:46, Walter Bright пишет:
On 2/23/2014 5:07 AM, Dmitry Olshansky wrote:
Part of the reason for forced inline is always inlining some core
primitives,
even in debug builds.
Right - and if the compiler won't do it, how does the error message help?
That programmer is instantly awar
On Sunday, 23 February 2014 at 20:40:44 UTC, Walter Bright wrote:
Generally, when I optimize at that level, I have a window open
on the assembler output of the compiler and I go back and forth
on the source code until I get the shape of the assembler I
need. Having compiler messages wouldn't be
On 2/23/2014 5:07 AM, Dmitry Olshansky wrote:
Part of the reason for forced inline is always inlining some core primitives,
even in debug builds.
Right - and if the compiler won't do it, how does the error message help?
> I wouldn't not like to ever have to get down and look at ASM for every
On 2/23/2014 11:04 AM, Dicebot wrote:
Optional recommendation for inlining already exists - it is current default.
That is not the point of the pragma. The point of always inlining is (as Manu
explained) some functions need to be inlined even in debug mode, as the code
would otherwise be too
On 2/23/2014 5:01 AM, Vladimir Panteleev wrote:
I think there should be some way to force the compiler to inline a function. As
a bonus, the error message can tell the programmer why the function could not be
inlined, allowing them to make the necessary adjustments.
Different compilers will have
On Sunday, 23 February 2014 at 20:29:19 UTC, Walter Bright wrote:
I'll add:
pragma(inline);
That's just going to confuse people, because they'll think *this*
forces inlining.
I'd prefer 3 separate states. pragma(inline), pragma(no_inline),
and pragma(default_inline) or something like t
On 2/23/2014 5:06 AM, Joseph Rushton Wakeling wrote:
So, if I understand right, a pragma(inline, true)
anywhere inside a function adds a compiler hint to always inline this function,
while with false it's a hint to _never_ do so, and no pragma at all gives the
usual compiler-decides situation?
On Sunday, 23 February 2014 at 12:25:20 UTC, Benjamin Thaut wrote:
Am 23.02.2014 13:07, schrieb Walter Bright:
http://wiki.dlang.org/DIP56
Manu has needed always inlining, and I've needed never
inlining. This
DIP proposes a simple solution.
Why a pragma? Can't we use a UDA and give it some
On Sunday, 23 February 2014 at 13:07:27 UTC, Dmitry Olshansky
wrote:
It's going to be near useless if it doesn't make sure inlining
happened.
Part of the reason for forced inline is always inlining some
core primitives, even in debug builds.
Optional recommendation for inlining already exists
On Sunday, 23 February 2014 at 12:50:58 UTC, Walter Bright wrote:
On 2/23/2014 4:38 AM, Dmitry Olshansky wrote:
Why pragma?
Answered in another post.
Also how exactly it is supposed to work:
T func(args)
{
...
pragma(inline, true);
...
}
How to return to normal state then?
On Sunday, 23 February 2014 at 13:07:27 UTC, Dmitry Olshansky
wrote:
23-Feb-2014 16:57, Walter Bright пишет:
On 2/23/2014 4:25 AM, Tove wrote:
The DIP should probably specify what happens if inlining
fails,
i.e. generate a compilation error.
I suspect that may cause problems, because differe
On 23 February 2014 14:19, Tove wrote:
> On Sunday, 23 February 2014 at 12:57:00 UTC, Walter Bright wrote:
>>
>> On 2/23/2014 4:25 AM, Tove wrote:
>>>
>>> The DIP should probably specify what happens if inlining fails,
>>> i.e. generate a compilation error.
>>
>>
>> I suspect that may cause proble
On Sunday, 23 February 2014 at 12:57:00 UTC, Walter Bright wrote:
On 2/23/2014 4:25 AM, Tove wrote:
The DIP should probably specify what happens if inlining fails,
i.e. generate a compilation error.
I suspect that may cause problems, because different compilers
will have different inlining ca
On Sunday, 23 February 2014 at 13:07:27 UTC, Dmitry Olshansky
wrote:
It's going to be near useless if it doesn't make sure inlining
happened.
I completely agree.
23-Feb-2014 16:57, Walter Bright пишет:
On 2/23/2014 4:25 AM, Tove wrote:
The DIP should probably specify what happens if inlining fails,
i.e. generate a compilation error.
I suspect that may cause problems, because different compilers will have
different inlining capabilities. I think it shou
On 23/02/2014 13:07, Walter Bright wrote:
http://wiki.dlang.org/DIP56
Manu has needed always inlining, and I've needed never inlining. This DIP
proposes a simple solution.
Sounds good in principle. So, if I understand right, a pragma(inline, true)
anywhere inside a function adds a compiler h
Am 23.02.2014 13:38, schrieb Dmitry Olshansky:
23-Feb-2014 16:07, Walter Bright пОÑеÑ:
http://wiki.dlang.org/DIP56
Manu has needed always inlining, and I've needed never inlining. This
DIP proposes a simple solution.
Why pragma? Also how exactly it is supposed to work:
pragma(inline, tr
On Sunday, 23 February 2014 at 12:57:00 UTC, Walter Bright wrote:
On 2/23/2014 4:25 AM, Tove wrote:
The DIP should probably specify what happens if inlining fails,
i.e. generate a compilation error.
I suspect that may cause problems, because different compilers
will have different inlining ca
On 2/23/2014 4:25 AM, Tove wrote:
The DIP should probably specify what happens if inlining fails,
i.e. generate a compilation error.
I suspect that may cause problems, because different compilers will have
different inlining capabilities. I think it should be a 'recommendation' to the
compile
On 2/23/2014 4:53 AM, ponce wrote:
On Sunday, 23 February 2014 at 12:07:40 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP56
Manu has needed always inlining, and I've needed never inlining. This DIP
proposes a simple solution.
This is great. I bet this will be useful.
I tend to prefer fo
On Sunday, 23 February 2014 at 12:07:40 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP56
Manu has needed always inlining, and I've needed never
inlining. This DIP proposes a simple solution.
This is great. I bet this will be useful.
I tend to prefer force-inline/force-not-inline at call
On 2/23/2014 4:31 AM, Andrej Mitrovic wrote:
What if you want to mark a series of functions to be inlined? E.g. in an entire
module:
-
module fast;
// ??
pragma(inline, true):
Vec vecSum();
Vec vecMul();
-
That can work because pragmas can have blocks associated with them.
On 2/23/2014 4:38 AM, Dmitry Olshansky wrote:
Why pragma?
Answered in another post.
Also how exactly it is supposed to work:
T func(args)
{
...
pragma(inline, true);
...
}
How to return to normal state then?
Not necessary when it's inside a function.
I'd strongly favor
On 2/23/2014 4:25 AM, Benjamin Thaut wrote:
Why a pragma? Can't we use a UDA and give it some special meaning inside the
compiler?
This shouldn't be an attribute, it's a hint to the compiler optimizer. Pragma is
ideally suited to that.
23-Feb-2014 16:25, Tove пишет:
On Sunday, 23 February 2014 at 12:07:40 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP56
Manu has needed always inlining, and I've needed never inlining. This
DIP proposes a simple solution.
yay, all for it! The DIP should probably specify what happens if
i
23-Feb-2014 16:07, Walter Bright пишет:
http://wiki.dlang.org/DIP56
Manu has needed always inlining, and I've needed never inlining. This
DIP proposes a simple solution.
Why pragma? Also how exactly it is supposed to work:
pragma(inline, true);
... //every declaration that follows is forcibly
On Sunday, 23 February 2014 at 12:07:40 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP56
Manu has needed always inlining, and I've needed never
inlining. This DIP proposes a simple solution.
What if you want to mark a series of functions to be inlined?
E.g. in an entire module:
-
On Sunday, 23 February 2014 at 12:07:40 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP56
Manu has needed always inlining, and I've needed never
inlining. This DIP proposes a simple solution.
yay, all for it! The DIP should probably specify what happens if
inlining fails, i.e. generate a
On 2/23/2014 4:21 AM, Mike wrote:
Is this a front-end thing or something specific to DMD? I'm wondering because
I'd like something like this for GDC and LCD when targeting ARM
microcontrollers. The inline keyword makes quite a significant performance
improvement in one of my current C++ project
Am 23.02.2014 13:07, schrieb Walter Bright:
http://wiki.dlang.org/DIP56
Manu has needed always inlining, and I've needed never inlining. This
DIP proposes a simple solution.
Why a pragma? Can't we use a UDA and give it some special meaning inside
the compiler?
On Sunday, 23 February 2014 at 12:07:40 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP56
Manu has needed always inlining, and I've needed never
inlining. This DIP proposes a simple solution.
Is this a front-end thing or something specific to DMD? I'm
wondering because I'd like somethin
http://wiki.dlang.org/DIP56
Manu has needed always inlining, and I've needed never inlining. This DIP
proposes a simple solution.
91 matches
Mail list logo
