On 7/27/14, 1:35 AM, Daniel Murphy wrote:
"Marc Schütz" " wrote in message
news:gefktpkzfnlryljvw...@forum.dlang.org...
IIRC the core reason is that expression nodes in the AST cannot
contain statements. Isn't it possible to create a "bridge" node type
that is allowed to appear in expressions,
"Marc Schütz" " wrote in message
news:gefktpkzfnlryljvw...@forum.dlang.org...
IIRC the core reason is that expression nodes in the AST cannot contain
statements. Isn't it possible to create a "bridge" node type that is
allowed to appear in expressions, but may also contain statements?
Sure,
On Sunday, 27 July 2014 at 07:48:18 UTC, Marc Schütz wrote:
On Sunday, 27 July 2014 at 07:01:52 UTC, Daniel Murphy wrote:
"Dicebot" wrote in message
news:xpjsskmamagclzoiw...@forum.dlang.org...
I can't PR but there were one by Kenji that did inline of
such calls in the frontend providing 100
On Sunday, 27 July 2014 at 01:06:43 UTC, Dicebot wrote:
On Sunday, 27 July 2014 at 00:43:41 UTC, Iain Buclaw via
Digitalmars-d wrote:
I'd be the sceptic of that. Which file exactly did he change?
(hint:
It may be ignored by other compilers).
Oh crap it is still open :D (and judging by comment
On Sunday, 27 July 2014 at 07:01:52 UTC, Daniel Murphy wrote:
"Dicebot" wrote in message
news:xpjsskmamagclzoiw...@forum.dlang.org...
I can't PR but there were one by Kenji that did inline of such
calls in the frontend providing 100% gurantee whatever backend
is used.
There is no 100% guar
"Dicebot" wrote in message news:xpjsskmamagclzoiw...@forum.dlang.org...
I can't PR but there were one by Kenji that did inline of such calls in
the frontend providing 100% gurantee whatever backend is used.
There is no 100% guarantee, the frontend's inliner is not capable of
inlining the maj
On 27 Jul 2014 02:10, "Dicebot via Digitalmars-d" <
digitalmars-d@puremagic.com> wrote:
>
> On Sunday, 27 July 2014 at 00:43:41 UTC, Iain Buclaw via Digitalmars-d
wrote:
>>
>> I'd be the sceptic of that. Which file exactly did he change? (hint:
>> It may be ignored by other compilers).
>
>
> Oh cra
On Sunday, 27 July 2014 at 00:43:41 UTC, Iain Buclaw via
Digitalmars-d wrote:
I'd be the sceptic of that. Which file exactly did he change?
(hint:
It may be ignored by other compilers).
Oh crap it is still open :D (and judging by comments there you
should more aware of what does than me) :
h
On 26 July 2014 23:24, Dicebot via Digitalmars-d
wrote:
> On Saturday, 26 July 2014 at 17:55:55 UTC, Marc Schütz wrote:
>>
>> The language reference on functions [1] says:
>>
>> "If a FunctionLiteral is immediately called, its inlining would be
>> enforced normally."
>>
>> How is this to be interp
On Saturday, 26 July 2014 at 22:24:40 UTC, Dicebot wrote:
On Saturday, 26 July 2014 at 17:55:55 UTC, Marc Schütz wrote:
The language reference on functions [1] says:
"If a FunctionLiteral is immediately called, its inlining
would be enforced normally."
How is this to be interpreted?
[1] htt
On Saturday, 26 July 2014 at 17:55:55 UTC, Marc Schütz wrote:
The language reference on functions [1] says:
"If a FunctionLiteral is immediately called, its inlining would
be enforced normally."
How is this to be interpreted?
[1] http://dlang.org/function
I can't PR but there were one by K
On Saturday, 26 July 2014 at 17:55:55 UTC, Marc Schütz wrote:
The language reference on functions [1] says:
"If a FunctionLiteral is immediately called, its inlining would
be enforced normally."
How is this to be interpreted?
[1] http://dlang.org/function
I would interpret that as saying i
Maybe we could have both declare site inlining and call site
inlining.
with declare site, what we mean is that this function's body is
used so commonly that we make it into a function only because we
don't want duplicate code, not because it should be a standalone
function.
with call site i
On Thursday, 20 March 2014 at 15:26:35 UTC, ponce wrote:
Now after this, even if the inlining become harmful for other
reasons, I want this inlining to be maintained, whatever the
cost, not subject to random rules I don't know of. When you
The rules aren't random. The inliner conceptually use
On 2014-03-19 09:35, Manu wrote:
I don't already have it, otherwise I'd be making use of it. D has no
control over the inliner. GDC/LDC offer attributes, but then it's really
annoying that D has no mechanism to make use of compiler-specific
attributes in a portable way (ie, attribute aliasing),
On Thursday, 20 March 2014 at 08:35:22 UTC, Ola Fosheim Grøstad
wrote:
Nothing prevents you to introduce exceptions as an extension
though. I want inline(0.5) as default, but also be able to
write inline(1) for inline always and inline(0) for inline
never.
func1(){} // implies inline(0.5) wei
On 21 March 2014 00:10,
<7d89a89974b0ff40.invalid@internationalized.invalid>wrote:
> Please note that 1 level mixin is not sufficient in the case of libraries.
> In too many cases you will not inline the function that does the work, only
> the interface wrapper.
>
I don't think I would ever want
Please note that 1 level mixin is not sufficient in the case of
libraries. In too many cases you will not inline the function
that does the work, only the interface wrapper.
On Thursday, 20 March 2014 at 12:31:33 UTC, Manu wrote:
I'm sorry. I really can't support any of these wildly complex
ideas.
They aren't actually complex, except tail-call optimization (but
that is well understood).
If you want to inline a second level, then write mixin in the
second level.
On 20 March 2014 18:35,
<7d89a89974b0ff40.invalid@internationalized.invalid>wrote:
> On Thursday, 20 March 2014 at 02:08:16 UTC, Manu wrote:
>
>> The problem is upside down. If you want to inline multiple levels, you
>> start from the leaves and move downwards, not from the root moving upwards
>>
On Thursday, 20 March 2014 at 02:08:16 UTC, Manu wrote:
The problem is upside down. If you want to inline multiple
levels, you
start from the leaves and move downwards, not from the root
moving upwards
Yes, that is true in cases where leaves are frequently visited.
Good point. I am most inter
I just want to add these reasons for having inlining despite
having compiler heuristics:
1. If you compile for embedded or PNACL on the web, you want a
small executable. That means the heuristics should not inline if
it increase the code size unless the programmer specified it in
the code. (O
On 20 March 2014 06:23,
<7d89a89974b0ff40.invalid@internationalized.invalid>wrote:
> On Wednesday, 19 March 2014 at 12:35:30 UTC, Manu wrote:
>
>> Okay, do you have use cases for any of this stuff? Are you just making it
>> up, or do you have significant experience to say this is what you need?
>>
On Wednesday, 19 March 2014 at 12:35:30 UTC, Manu wrote:
Okay, do you have use cases for any of this stuff? Are you just
making it
up, or do you have significant experience to say this is what
you need?
I don't need anything, I hand optimize prematurely. And I don't
want to do that.
But yes
On 19 March 2014 19:16,
<7d89a89974b0ff40.invalid@internationalized.invalid>wrote:
> On Wednesday, 19 March 2014 at 08:35:53 UTC, Manu wrote:
>
>> The idea of eliminating common sub-expressions suggests that there _are_
>> common sub-expressions, which aren't affected by the function arguments.
>>
On Wednesday, 19 March 2014 at 08:35:53 UTC, Manu wrote:
The idea of eliminating common sub-expressions suggests that
there _are_
common sub-expressions, which aren't affected by the function
arguments.
This case is highly unusual in my experience.
Not if you delay optimization until profilin
On 19 March 2014 16:18,
<7d89a89974b0ff40.invalid@internationalized.invalid>wrote:
> On Wednesday, 19 March 2014 at 01:28:48 UTC, Manu wrote:
>
>> In the case you do want to inline the whole tree, you can just cascade the
>> mixin through the stack. In the case you suggest which flattens the tree
On Wednesday, 19 March 2014 at 01:28:48 UTC, Manu wrote:
In the case you do want to inline the whole tree, you can just
cascade the
mixin through the stack. In the case you suggest which flattens
the tree by
default, we've lost control; how to tell it only to do it for
one level
without hacks?
On 18 March 2014 23:11,
<7d89a89974b0ff40.invalid@internationalized.invalid>wrote:
> On Saturday, 15 March 2014 at 04:17:06 UTC, Manu wrote:
>
>> I'd say it should inline only func. Any sub-calls are subject to the
>> regular inline heuristics.
>>
>
> I agree with you that explicit inlining is abs
On Saturday, 15 March 2014 at 04:17:06 UTC, Manu wrote:
I'd say it should inline only func. Any sub-calls are subject
to the
regular inline heuristics.
I agree with you that explicit inlining is absolutely necessary
and that call site inlining is highly desirable. However, I think
that the c
On 18 March 2014 06:37, Andrei Alexandrescu
wrote:
> On 3/17/14, 9:10 AM, Manu wrote:
>
>> On 18 March 2014 01:36, Andrei Alexandrescu
>> mailto:seewebsiteforem...@erdani.org>>
>>
>> wrote:
>>
>>
>> I'd like to see a solution to inlining along the lines of "pliz pliz
>> inline" (best effor
On 3/17/14, 9:10 AM, Manu wrote:
On 18 March 2014 01:36, Andrei Alexandrescu
mailto:seewebsiteforem...@erdani.org>>
wrote:
I'd like to see a solution to inlining along the lines of "pliz pliz
inline" (best effort) and "never inline".
Outlining only at a specific call site is seldom
On 18 March 2014 01:36, Andrei Alexandrescu
wrote:
>
> I'd like to see a solution to inlining along the lines of "pliz pliz
> inline" (best effort) and "never inline".
>
> Outlining only at a specific call site is seldom needed and when it is
> it's trivially achievable with a noinline function fo
On 3/17/14, 6:26 AM, Manu wrote:
On 15 March 2014 14:55, Manu mailto:turkey...@gmail.com>> wrote:
On 15 March 2014 14:33, Daniel Murphy mailto:yebbliesnos...@gmail.com>> wrote:
"Manu" mailto:turkey...@gmail.com>> wrote
in message
news:mailman.128.1394856947.__23258.d
On 15 March 2014 14:55, Manu wrote:
> On 15 March 2014 14:33, Daniel Murphy wrote:
>
>> "Manu" wrote in message
>> news:mailman.128.1394856947.23258.digitalmar...@puremagic.com...
>>
>> > Haven't we already agreed a pragma for force inline should be >
>>> implemented. Or is
>>> > that somethin
On 15 March 2014 14:33, Daniel Murphy wrote:
> "Manu" wrote in message news:mailman.128.1394856947.
> 23258.digitalmar...@puremagic.com...
>
> > Haven't we already agreed a pragma for force inline should be >
>> implemented. Or is
>> > that something I have dreamed?
>>
>> It's been discussed. I
"Manu" wrote in message
news:mailman.128.1394856947.23258.digitalmar...@puremagic.com...
> Haven't we already agreed a pragma for force inline should be
> implemented. Or is
> that something I have dreamed?
It's been discussed. I never agreed to it (I _really_ don't like it), but
I'll take
On 15 March 2014 04:02, Michel Fortin wrote:
> On 2014-03-14 17:57:59 +, Jacob Carlborg said:
>
> int output = mixin func(10); // the 'mixin' keyword seems to kinda 'get
>>>
>>
>> I think this is the best syntax of these three alternatives.
>>
>
> Maybe, but what does it do? Should it just
On 15 March 2014 03:57, Jacob Carlborg wrote:
> On 2014-03-14 07:21, Manu wrote:
>
>> So, I'm constantly running into issues with not having control over
>> inline.
>> I've run into it again doing experiments in preparation for my dconf
>> talk...
>>
>> I have identified 2 cases which come up reg
On Friday, 14 March 2014 at 22:12:38 UTC, Nick Sabalausky wrote:
On 3/14/2014 8:37 AM, Manu wrote:
On 14 March 2014 22:02, John Colvin
wrote:
I don't know how good compilers are at taking this sort of
thing into
account already.
I don't know if they try or not, but I can say from experie
On 3/14/2014 8:37 AM, Manu wrote:
On 14 March 2014 22:02, John Colvin wrote:
I don't know how good compilers are at taking this sort of thing into
account already.
I don't know if they try or not, but I can say from experience that results
are generally unreliable.
I would never depend on t
On 2014-03-14 19:02, Michel Fortin wrote:
Maybe, but what does it do? Should it just inline the call to func? Or
should it inline recursively every call inside func? Or maybe something
in the middle?
I guess Manu needs to answer this one.
--
/Jacob Carlborg
On 3/14/14, 1:42 PM, Paulo Pinto wrote:
Am 14.03.2014 19:09, schrieb David Gileadi:
On 3/13/14, 11:21 PM, Manu wrote:
My feeling is that an ideal solution would be something like an
enhancement which would allow the 'mixin' keyword to be used with
regular function calls.
What this would do is '
Am 14.03.2014 19:09, schrieb David Gileadi:
On 3/13/14, 11:21 PM, Manu wrote:
My feeling is that an ideal solution would be something like an
enhancement which would allow the 'mixin' keyword to be used with
regular function calls.
What this would do is 'mix in' the function call at this locatio
On 3/13/14, 11:21 PM, Manu wrote:
My feeling is that an ideal solution would be something like an
enhancement which would allow the 'mixin' keyword to be used with
regular function calls.
What this would do is 'mix in' the function call at this location, ie,
effectively inline that particular cal
On 2014-03-14 17:57:59 +, Jacob Carlborg said:
int output = mixin func(10); // the 'mixin' keyword seems to kinda 'get
I think this is the best syntax of these three alternatives.
Maybe, but what does it do? Should it just inline the call to func? Or
should it inline recursively every
On 2014-03-14 07:21, Manu wrote:
So, I'm constantly running into issues with not having control over inline.
I've run into it again doing experiments in preparation for my dconf talk...
I have identified 2 cases which come up regularly:
1. A function that should always be inline unconditionall
On 14 March 2014 22:02, John Colvin wrote:
>
>
> Thanks for the explanations.
>
> Another use case is to aid propogation of compile-time information for
> optimisation.
> A function might look like a poor candidate for inlining for other
> reasons, but if there's a statically known (to the caller)
John Colvin:
Another use case is to aid propogation of compile-time
information for optimisation.
A function might look like a poor candidate for inlining for
other reasons, but if there's a statically known (to the
caller) integer parameter coming in that will be used to decide
a loop length
On Friday, 14 March 2014 at 11:04:34 UTC, Manu wrote:
On 14 March 2014 18:03, John Colvin
wrote:
As much as I like the idea:
Something always tells me this is the compilers job... What
clever
reasoning are you applying that the compiler's inliner can't?
It seems like
a different situation
On 14 March 2014 18:03, John Colvin wrote:
> As much as I like the idea:
>
> Something always tells me this is the compilers job... What clever
> reasoning are you applying that the compiler's inliner can't? It seems like
> a different situation to say SIMD code, where correctly structuring loops
On Friday, 14 March 2014 at 08:03:04 UTC, John Colvin wrote:
Something always tells me this is the compilers job
If all methods are virtual by default, how can the compiler
inline the code? Properties are a great example where I'd want to
both final and inline them in quite a few cases. In thos
Something always tells me this is the compilers job... What
clever reasoning are you applying that the compiler's inliner
can't? It seems like a different situation to say SIMD code,
where correctly structuring loops can require a lot of
gymnastics that the compiler can't or won't (floating p
On Friday, 14 March 2014 at 08:03:04 UTC, John Colvin wrote:
As much as I like the idea:
Something always tells me this is the compilers job... What
clever reasoning are you applying that the compiler's inliner
can't? It seems like a different situation to say SIMD code,
where correctly struc
On Friday, 14 March 2014 at 06:21:27 UTC, Manu wrote:
So, I'm constantly running into issues with not having control
over inline.
I've run into it again doing experiments in preparation for my
dconf talk...
I have identified 2 cases which come up regularly:
1. A function that should always be
On 11/02/2011 06:35, Walter Bright wrote:
I hate not being able to force functions to be inline. A consequence is that
you can't
fully interface certain APIs without an extra .lib over what would be needed in
C(++).
You cannot force inlining in C(++) either. The inline keyword is only a
sug
spir wrote:
On 02/14/2011 04:42 AM, Walter Bright wrote:
In that vein, it is exceedingly miserable that assemblers do not
accept struct
declarations in C format. I always have to painstakingly translate
them, and
double check that all the offsets and alignment are correct. What a pain.
Does
On 2/14/11, bearophile wrote:
> spir:
>
>> Does D's inline asm allow that?
>
> I don't think so (but I don't know what you are able to do with static
> structs defined outside the asm block).
>
I think the asm in DMD is the same one used in DMC, so this page
should be helpfull:
http://www.digital
spir:
> Does D's inline asm allow that?
I don't think so (but I don't know what you are able to do with static structs
defined outside the asm block).
> "In the same vein", what about a low-level language with (un)named tuples?
I have suggested some kind of annotation to allow D std.typecons.
On 02/14/2011 04:42 AM, Walter Bright wrote:
In that vein, it is exceedingly miserable that assemblers do not accept struct
declarations in C format. I always have to painstakingly translate them, and
double check that all the offsets and alignment are correct. What a pain.
Does D's inline asm
On Sun, 13 Feb 2011 09:57:52 +0200, so wrote:
> Ok i stop, looks like i fail to make my point to anyone :)
I see your point and I agree with you.
Cheers
Piotrek
bearophile wrote:
Walter:
The inline assembler can't do everything a standalone assembler can, but
what it does it does well enough, and is a pleasure (to me) to use.
The D inline assembler has another purpose you have not underlined: it's a
didactic tool to learn some assembly without nothin
On Mon, 14 Feb 2011 00:58:48 +0200, Walter Bright
wrote:
so wrote:
If you are against this reasoning, i don't have any idea why D has
inline assembly, which again targets a very small audience.
The inline assembler is s much easier to deal with than the
miserable, fugly assemblers f
Adam D. Ruppe:
> All of this has been done, and caught on to a huge degree.
> They called that asm+types language "C"
This is part of what I was referring to:
http://www.cs.cornell.edu/talc/
Bye,
bearophile
bearophile wrote:
> There is not much intrinsic in the asm language that forces people
> to not define and use a good type system on asm instructions to
> catch programming bugs, to indent asm code well, to use a modern
> IDE on asm code, and so on.
All of this has been done, and caught on to a hu
Walter:
> The inline assembler can't do everything a standalone assembler can, but what
> it
> does it does well enough, and is a pleasure (to me) to use.
The D inline assembler has another purpose you have not underlined: it's a
didactic tool to learn some assembly without nothing but the nor
so wrote:
If you are against this reasoning, i don't have any idea why D has
inline assembly, which again targets a very small audience.
The inline assembler is s much easier to deal with than the miserable, fugly
assemblers found on the various systems.
The Linux as assembler is designe
Ok i stop, looks like i fail to make my point to anyone :)
How many times do I need to repeat I do not want to force inlining? Or
what else are you talking about?
And this is why it doesn't make sense.
What are we doing here? Are we trying to find practical solutions to real
world problems or just showing how useless things D can do?
Instead, I wan
On 02/13/2011 04:13 AM, so wrote:
On Sat, 12 Feb 2011 13:20:36 +0200, spir wrote:
On 02/12/2011 12:15 PM, Jim wrote:
Sorry about that, but I think that is a closely related discussion. @inline
is certainly a verb -- even imperative mood, so not just asking for
information.
Why do you need inf
There are all kinds of extensions popular in C++, but they are not part
of Standard C++.
That is because if they don't support an extension (where standard failed
to provide), people would switch to different compiler that would.
If you mean there are many things a language can't possibly cop
On Sat, 12 Feb 2011 13:20:36 +0200, spir wrote:
On 02/12/2011 12:15 PM, Jim wrote:
Sorry about that, but I think that is a closely related discussion.
@inline is certainly a verb -- even imperative mood, so not just asking
for information.
Why do you need information if you can't affect th
"Walter Bright" wrote in message
news:ij41q1$1j1q$2...@digitalmars.com...
> bearophile wrote:
>>> While in isolation that's a good idea, how far should it be taken?
>>> Should the compiler emit information on which variables wound up in
>>> which registers, and why? What about other of the myr
ivan Wrote:
> Jim Wrote:
>
> > spir Wrote:
> >
> > > On 02/12/2011 12:15 PM, Jim wrote:
> > > > Sorry about that, but I think that is a closely related discussion.
> > > > @inline is certainly a verb -- even imperative mood, so not just asking
> > > > for information.
> > > > Why do you need i
ivan Wrote:
> Jim Wrote:
>
> > spir Wrote:
> >
> > > On 02/12/2011 12:15 PM, Jim wrote:
> > > > Sorry about that, but I think that is a closely related discussion.
> > > > @inline is certainly a verb -- even imperative mood, so not just asking
> > > > for information.
> > > > Why do you need i
Jim Wrote:
> spir Wrote:
>
> > On 02/12/2011 12:15 PM, Jim wrote:
> > > Sorry about that, but I think that is a closely related discussion.
> > > @inline is certainly a verb -- even imperative mood, so not just asking
> > > for information.
> > > Why do you need information if you can't affect
On 02/12/2011 12:42 PM, Jim wrote:
spir Wrote:
On 02/12/2011 12:15 PM, Jim wrote:
Sorry about that, but I think that is a closely related discussion. @inline is
certainly a verb -- even imperative mood, so not just asking for information.
Why do you need information if you can't affect the ou
spir Wrote:
> On 02/12/2011 12:15 PM, Jim wrote:
> > Sorry about that, but I think that is a closely related discussion. @inline
> > is certainly a verb -- even imperative mood, so not just asking for
> > information.
> > Why do you need information if you can't affect the outcome?
>
> I want t
On 02/12/2011 12:15 PM, Jim wrote:
Sorry about that, but I think that is a closely related discussion. @inline is
certainly a verb -- even imperative mood, so not just asking for information.
Why do you need information if you can't affect the outcome?
I want to know it. First, because it's va
spir Wrote:
> On 02/11/2011 09:49 PM, bearophile wrote:
> > Jim:
> >
> >> If forced inlining is to be supported
> >
> > spir was asking for a list of functions that the compiled has inlined, not
> > for a forced inlining functionality.
>
> You are (nearly) right, Bearophile. More precisely, I ra
On 02/12/2011 10:46 AM, Christopher Nicholson-Sauls wrote:
All of this is hardly related to the simple feature I initially asked for:
string escString (string s) @tellmeifnotinlined {
s2 = s.replace("\n","\\n");
s2 = s.replace("\t","\\t");
return s2;
>
> All of this is hardly related to the simple feature I initially asked for:
>
> string escString (string s) @tellmeifnotinlined {
> s2 = s.replace("\n","\\n");
> s2 = s.replace("\t","\\t");
> return s2;
> }
> void show (X x) {
> // ... use es
Register allocation is far more important than inlining. Why not give
information about why a variable was not enregistered?
I am sorry Walter but your stance on this more politic than a practical
fact, it is not you, sounds like you secured a professorship!. :)
Now i started to see the rea
All of this is hardly related to the simple feature I initially asked
for:
string escString (string s) @tellmeifnotinlined {
s2 = s.replace("\n","\\n");
s2 = s.replace("\t","\\t");
return s2;
}
void show (X x) {
// ... us
Register allocation is far more important than inlining. Why not give
information about why a variable was not enregistered?
I am sorry Walter but your stance on this more politic than a practical
fact, it is not you, sounds like you secured a professorship!. :)
bearophile wrote:
There are two groups of register allocation algorithms. The very
fast ones, and the more precise ones. You even have perfect ones. Experience
has shown that the difference in runtime performance between the precise
algorithm and the perfect ones is often about 5% (this measured
spir wrote:
On 02/11/2011 08:11 PM, Walter Bright wrote:
bearophile wrote:
While in isolation that's a good idea, how far should it be taken?
Should
the compiler emit information on which variables wound up in which
registers, and why? What about other of the myriad of compiler
optimizations?
On 02/11/2011 10:08 PM, bearophile wrote:
spir:
About inline, note that no-one asks for information on every potentially
inlinable func, blindly. But having a way to know that about /this/ func one is
wondering about would be great: just append @inline to it, recompile, et voilà!
you know :-) (
On 02/11/2011 10:22 PM, Christopher Nicholson-Sauls wrote:
On 02/11/11 14:26, Jim wrote:
Jim Wrote:
bearophile Wrote:
The LLVM back-end of LDC is able to inline much more, but even here a list of
inlined/not inlined functions helps. D is almost a system language, so
sometimes you need to go
On 02/11/2011 09:49 PM, bearophile wrote:
Jim:
If forced inlining is to be supported
spir was asking for a list of functions that the compiled has inlined, not for
a forced inlining functionality.
You are (nearly) right, Bearophile. More precisely, I rather wish @inline on a
given func to
On 02/11/11 14:26, Jim wrote:
> Jim Wrote:
>
>> bearophile Wrote:
>>> The LLVM back-end of LDC is able to inline much more, but even here a list
>>> of inlined/not inlined functions helps. D is almost a system language, so
>>> sometimes you need to go lower level (or you just need a program that
spir:
> About inline, note that no-one asks for information on every potentially
> inlinable func, blindly. But having a way to know that about /this/ func one
> is
> wondering about would be great: just append @inline to it, recompile, et
> voilà !
> you know :-) (provided you can interpret
Walter:
> bearophile wrote:
> >> While in isolation that's a good idea, how far should it be taken? Should
> >> the
> >> compiler emit information on which variables wound up in which registers,
> >> and
> >> why? What about other of the myriad of compiler optimizations?
> >
> > Inlining is a
Jim:
> If forced inlining is to be supported
spir was asking for a list of functions that the compiled has inlined, not for
a forced inlining functionality.
Bye,
bearophile
Jim Wrote:
> bearophile Wrote:
> > The LLVM back-end of LDC is able to inline much more, but even here a list
> > of inlined/not inlined functions helps. D is almost a system language, so
> > sometimes you need to go lower level (or you just need a program that's not
> > too much slow).
>
>
>
On 02/11/2011 08:11 PM, Walter Bright wrote:
bearophile wrote:
While in isolation that's a good idea, how far should it be taken? Should
the compiler emit information on which variables wound up in which
registers, and why? What about other of the myriad of compiler optimizations?
Inlining is
bearophile Wrote:
> The LLVM back-end of LDC is able to inline much more, but even here a list of
> inlined/not inlined functions helps. D is almost a system language, so
> sometimes you need to go lower level (or you just need a program that's not
> too much slow).
If forced inlining is to be
bearophile wrote:
While in isolation that's a good idea, how far should it be taken? Should the
compiler emit information on which variables wound up in which registers, and
why? What about other of the myriad of compiler optimizations?
Inlining is an important optimization, so give this infor
On 02/11/2011 07:08 PM, bearophile wrote:
Jim:
I rarely need to go that low-level.
Two times I have had D1 code that was too much slow compared to equivalent C
code. After profiling and some changes I have understood that the cause was an
important missing inline. With a list of the inlined
Jim:
> I rarely need to go that low-level.
Two times I have had D1 code that was too much slow compared to equivalent C
code. After profiling and some changes I have understood that the cause was an
important missing inline. With a list of the inlined functions (as done by
CommonLisp some comp
1 - 100 of 171 matches
Mail list logo
