On Wed, 29 Jul 2015 18:35:36 +, David Nadlinger wrote:
On Wednesday, 29 July 2015 at 04:26:36 UTC, ketmar wrote:
yet that ship has sailed, i think.
It hasn't yet. 2.068.0 will be the first release to include the pragma.
but one has to convince Walter, and it's not the easiest thing to
On 31 July 2015 at 14:06, Steven Schveighoffer via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 7/30/15 4:37 PM, Jonathan M Davis wrote:
On Thursday, 30 July 2015 at 18:41:51 UTC, Steven Schveighoffer wrote:
OK, that is what I first thought. Then I thought it meant that for
that
On Tuesday, 28 July 2015 at 22:12:21 UTC, David Nadlinger wrote:
I do think it is terribly confusing. pragma(inline) does not
cause any inlining by itself at all. It just means to let the
compiler do what it normally does (i.e. try to inline if
-inline is specified).
I suppose people were
On 7/30/15 4:37 PM, Jonathan M Davis wrote:
On Thursday, 30 July 2015 at 18:41:51 UTC, Steven Schveighoffer wrote:
OK, that is what I first thought. Then I thought it meant that for
that function, it works as if -inline was passed on the command line
(i.e. try to inline if possible, if not,
Steven Schveighoffer wrote in message
news:mp86be$8f2$1...@digitalmars.com...
the only thing I can thing of is that true/false are (or have the
potential to be in this context) expressions, which means one could use
compile-time logic to specify inlining. The same wouldn't be true of
On Thursday, 30 July 2015 at 18:41:51 UTC, Steven Schveighoffer
wrote:
So you are saying the first interpretation is correct?
As far as I can see, this is what the implementation currently
does, yes.
— David
On Thursday, 30 July 2015 at 18:41:51 UTC, Steven Schveighoffer
wrote:
OK, that is what I first thought. Then I thought it meant that
for that function, it works as if -inline was passed on the
command line (i.e. try to inline if possible, if not, don't
worry about it). So you are saying the
On 7/28/15 6:12 PM, David Nadlinger wrote:
On Tuesday, 28 July 2015 at 21:29:45 UTC, Steven Schveighoffer wrote:
On 7/28/15 5:28 PM, Steven Schveighoffer wrote:
On 7/28/15 5:24 PM, David Nadlinger wrote:
On Tuesday, 28 July 2015 at 15:56:52 UTC, Jonathan M Davis wrote:
It[Accepting
On Wednesday, 29 July 2015 at 18:34:34 UTC, David Nadlinger wrote:
Unless I misread the source, it does not mean that at all.
Instead, it leads to the same behavior as if no pragma(inline)
was specified at all, i.e. use the normal heuristics if -inline
is specified, and do not do any inlining
On Tuesday, 28 July 2015 at 23:55:00 UTC, Brandon Ragland wrote:
On Tuesday, 28 July 2015 at 21:28:30 UTC, Steven Schveighoffer
wrote:
On 7/28/15 5:24 PM, David Nadlinger wrote:
[…]
pragma(inline);
pragma(inline, true);
pragma(inline, false);
There is no way to represent those as a single
On 29 July 2015 at 20:34, David Nadlinger via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Tuesday, 28 July 2015 at 23:55:00 UTC, Brandon Ragland wrote:
On Tuesday, 28 July 2015 at 21:28:30 UTC, Steven Schveighoffer wrote:
On 7/28/15 5:24 PM, David Nadlinger wrote:
[…]
On Wednesday, 29 July 2015 at 04:26:36 UTC, ketmar wrote:
yet that ship has sailed, i think.
It hasn't yet. 2.068.0 will be the first release to include the
pragma.
— David
On Tuesday, 28 July 2015 at 21:28:30 UTC, Steven Schveighoffer
wrote:
On 7/28/15 5:24 PM, David Nadlinger wrote:
On Tuesday, 28 July 2015 at 15:56:52 UTC, Jonathan M Davis
wrote:
It[Accepting Booleans]'s far more flexible in generic code.
It's the other way round. pragma(inline) has
On Tuesday, 28 July 2015 at 21:30:11 UTC, Jonathan M Davis wrote:
On Tuesday, 28 July 2015 at 21:24:31 UTC, David Nadlinger wrote:
On Tuesday, 28 July 2015 at 15:56:52 UTC, Jonathan M Davis
wrote:
It[Accepting Booleans]'s far more flexible in generic code.
It's the other way round.
On Tuesday, 28 July 2015 at 13:30:52 UTC, Marc Schütz wrote:
On Tuesday, 28 July 2015 at 12:46:25 UTC, Adrian Matoga wrote:
On Tuesday, 28 July 2015 at 02:05:56 UTC, Daniel Murphy wrote:
tcak wrote in message
news:psflpqqpsukpfgpzh...@forum.dlang.org...
Why not like pragma(inline, [try
On Tuesday, 28 July 2015 at 12:46:25 UTC, Adrian Matoga wrote:
On Tuesday, 28 July 2015 at 02:05:56 UTC, Daniel Murphy wrote:
tcak wrote in message
news:psflpqqpsukpfgpzh...@forum.dlang.org...
Why not like pragma(inline, [try | force | no]) ?
Walter liked the boolean version, which
(inline, [try | force | no]) ?
Walter liked the boolean version, which is certainly better than
nothing.
I regret I missed this pull request and the chance to vote for
always/never proposed by yebblies, which hit the right neurons in
reader's brain instantly, unlike the generic true/false.
Someone
On Tuesday, 28 July 2015 at 15:15:58 UTC, Steven Schveighoffer
wrote:
the only thing I can thing of is that true/false are (or have
the potential to be in this context) expressions, which means
one could use compile-time logic to specify inlining. The same
wouldn't be true of arbitrary
On Tuesday, 28 July 2015 at 02:05:56 UTC, Daniel Murphy wrote:
tcak wrote in message
news:psflpqqpsukpfgpzh...@forum.dlang.org...
Why not like pragma(inline, [try | force | no]) ?
Walter liked the boolean version, which is certainly better
than nothing.
I regret I missed this pull
On Tue, 28 Jul 2015 11:15:58 -0400, Steven Schveighoffer wrote:
the only thing I can thing of is that true/false are (or have the
potential to be in this context) expressions, which means one could use
compile-time logic to specify inlining. The same wouldn't be true of
arbitrary identifiers.
On Tuesday, 28 July 2015 at 15:15:58 UTC, Steven Schveighoffer
wrote:
the only thing I can thing of is that true/false are (or have
the potential to be in this context) expressions, which means
one could use compile-time logic to specify inlining. The same
wouldn't be true of arbitrary
On Tuesday, 28 July 2015 at 15:56:52 UTC, Jonathan M Davis wrote:
It[Accepting Booleans]'s far more flexible in generic code.
It's the other way round. pragma(inline) has currently *three*
behaviors:
pragma(inline);
pragma(inline, true);
pragma(inline, false);
There is no way to represent
On 7/28/15 5:28 PM, Steven Schveighoffer wrote:
On 7/28/15 5:24 PM, David Nadlinger wrote:
On Tuesday, 28 July 2015 at 15:56:52 UTC, Jonathan M Davis wrote:
It[Accepting Booleans]'s far more flexible in generic code.
It's the other way round. pragma(inline) has currently *three* behaviors:
On 7/28/15 5:24 PM, David Nadlinger wrote:
On Tuesday, 28 July 2015 at 15:56:52 UTC, Jonathan M Davis wrote:
It[Accepting Booleans]'s far more flexible in generic code.
It's the other way round. pragma(inline) has currently *three* behaviors:
pragma(inline);
pragma(inline, true);
On Tuesday, 28 July 2015 at 21:24:31 UTC, David Nadlinger wrote:
On Tuesday, 28 July 2015 at 15:56:52 UTC, Jonathan M Davis
wrote:
It[Accepting Booleans]'s far more flexible in generic code.
It's the other way round. pragma(inline) has currently *three*
behaviors:
pragma(inline);
On Tuesday, 28 July 2015 at 21:29:45 UTC, Steven Schveighoffer
wrote:
On 7/28/15 5:28 PM, Steven Schveighoffer wrote:
On 7/28/15 5:24 PM, David Nadlinger wrote:
On Tuesday, 28 July 2015 at 15:56:52 UTC, Jonathan M Davis
wrote:
It[Accepting Booleans]'s far more flexible in generic code.
It's
to accommodate DMD, which has
some restrictions about which functions can be inlined.
Why not like pragma(inline, [try | force | no]) ?
tcak wrote in message news:psflpqqpsukpfgpzh...@forum.dlang.org...
Why not like pragma(inline, [try | force | no]) ?
Walter liked the boolean version, which is certainly better than nothing.
) worked vs how it should work. In particular, I
think that there was a big dispute over whether pragma(inline,
true) should force inlining outright or make it so that it gave
you an error if it wasn't inlined. I'd have to go find that
discussion and dig through it though to know for sure what
there again... if I were shipping this product, I would NEED
forceinline +
force-not-inline.
I don't know if it's possible right now with GDC/LDC but did you
try PGO+LTO ?
Just curious.
that there was a big dispute over whether pragma(inline,
true) should force inlining outright or make it so that it gave
you an error if it wasn't inlined. I'd have to go find that
discussion and dig through it though to know for sure what was
being discussed exactly. I paid some attention to it, but not a
lot
characteristics in
hot-loop situations.
I know this has come up time and time again, but I just want
to put it out
there again... if I were shipping this product, I would NEED
forceinline +
force-not-inline.
You could use GDC and @attribute(forceinline) and
@attribute(noinline). But I agree
time and time again, but I just want
to put it out
there again... if I were shipping this product, I would NEED
forceinline +
force-not-inline.
You could use GDC and @attribute(forceinline) and
@attribute(noinline). But I agree it would be nice to have
something like that as a part
in point might be a call that at first glance doesn't get
called often, but when in production, gets called thousands of
times. That could be massive savings if it were able to force
inline.
-Brandon
It looks like support is being considered:
http://dlang.org/pragma.html#inline
Bump.
Will forceinline be introduced?
there again... if I were shipping this product, I would NEED
forceinline +
force-not-inline.
You could use GDC and @attribute(forceinline) and
@attribute(noinline). But I agree it would be nice to have
something like that as a part of the language.
shipping this product, I would NEED
forceinline + force-not-inline.
I know D likes to try and intelligently inline code, but in these very
high performance cases, I know what's best for my code, and I have also
shipped this product commercially before. I know exactly what was
required of it from months
On 18 March 2012 10:56, Adrian adrian.remove-nos...@veith-system.de wrote:
+1
Currently I use string mixins to force inlining - but that's uggly
Yeah, that's not an acceptable workaround. I couldn't write
commercial/large-team code that way.
forceinline +
force-not-inline.
I know D likes to try and intelligently inline code, but in these very high
performance cases, I know what's best for my code, and I have also shipped
this product commercially before. I know exactly what was required of it
from months of meticulous performance profiling
this product, I would NEED
forceinline + force-not-inline.
I know D likes to try and intelligently inline code, but in these very
high performance cases, I know what's best for my code, and I have also
shipped this product commercially before. I know exactly what was
required of it from months
On 3/17/12, Manu turkey...@gmail.com wrote:
I just started writing an emulator in D for some fun
FWIW another dev did this http://code.google.com/p/pspemu/
On 18 March 2012 01:51, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
On 3/17/12, Manu turkey...@gmail.com wrote:
I just started writing an emulator in D for some fun
FWIW another dev did this http://code.google.com/p/pspemu/
Yeah, I've seen that. But it's a PC app, and JITs. Different
42 matches
Mail list logo
