[Bug 67] Imported functions are not inlined.

d-bugmail at puremagic.com d-bugmail at puremagic.com
Sat Mar 25 09:45:14 PST 2006


http://d.puremagic.com/bugzilla/show_bug.cgi?id=67





------- Comment #2 from godaves at yahoo.com  2006-03-25 11:45 -------
>That's because in inline.c, when checking to see if a function can be inlined,
>it checks to see if the semantic run has happened yet.  Which makes sense,
>because that needs to happen to inline it.
>
>Simply adding a semantic3 to Import fixes this (because then imported functions
>are get a sematic run), although honestly I'm not sure if that's the right fix.

Good catch! I'll try and find the time to update my copy of the dmd front-end
and give it a shot. Given D is performance orientated, this needs to work as
people will expect it to.

> It may be a lot slower to do this, and it may certainly have been left out on
>purpose.

Yea, but in any case -inline doesn't have to be used and won't be for most of
the code/debug/run cycle, right? The DMD compiler is so fast that even for
release builds I can't see this causing a big problem requiring things like
"grid compiling" <g>.

If code size is a concern, most of phobos.lib is built w/o -inline right now,
and again, it doesn't have to be used if it severly bloats the code. Sometimes
inlining can even reduce code size.

>
>Maybe it can be sematic3'd only when -inline is passed, if that can work.
>

If that is the solution, then it shouldn't be a problem to implement because
the compiler switches are global.

Hmmm - could semantic3 just be run in inline.c if it has not been run yet (as
in the case of an imported function)? In any case the import and it's contents
will have already had semantic() run during the 1st semantic pass because
Import::semantic() calls Module::semantic() to process all the symbols in that
module, including other imports, so semantic() is always done recursively
before the inline pass. So, those functions should be ready for semantic3()
before the inline pass... Cool!

If the fix is really that easy then there is no reason not to fix this right
away. The worst that could happen is that it will flush out problems with
-inline that people will eventually encounter anyhow so the sooner the better I
think.

>
>Really, I must say, I always expected that this worked and now wonder how much
>benefit/deteriment it would give if it did.
>

It can make a very big difference for some pretty commonly used imported
functions, and it'll be expected by users of every other language that inlines. 

I have not run into a case where it makes any executable slower and can't
imagine it being a detriment except in the potential/odd case where it does
severly bloat the code.

Thanks,
- Dave

>Thanks,
>-[Unknown]


-- 




More information about the Digitalmars-d-bugs mailing list