www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Excluding symbols

reply Etienne <etcimon gmail.com> writes:
I've been using a lot of CTFE in my libraries and this has had the side 
effect of increasing my link time beyond 13 seconds. There's a pretty 
big chunk of those symbols being exported that are used only for 
evaluating mixins.

Would there be a way to specify something in the lines of `extern 
(none):` or `intern:`?
Apr 20 2015
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 20 Apr 2015 09:22:17 -0400, Etienne wrote:


 I've been using a lot of CTFE in my libraries and this has had the side
 effect of increasing my link time beyond 13 seconds. There's a pretty
 big chunk of those symbols being exported that are used only for
 evaluating mixins.
=20
 Would there be a way to specify something in the lines of `extern
 (none):` or `intern:`?


i think you should make ER for this. it will be fine if there will be the=20
way to tell compiler to skip code generation for some functions which=20
used only in CTFE.=
Apr 20 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 20 Apr 2015 13:34:47 +0000, ketmar wrote:


 On Mon, 20 Apr 2015 09:22:17 -0400, Etienne wrote:
=20

 I've been using a lot of CTFE in my libraries and this has had the side
 effect of increasing my link time beyond 13 seconds. There's a pretty
 big chunk of those symbols being exported that are used only for
 evaluating mixins.
=20
 Would there be a way to specify something in the lines of `extern
 (none):` or `intern:`?


=20
 i think you should make ER for this. it will be fine if there will be
 the way to tell compiler to skip code generation for some functions
 which used only in CTFE.


by the way, maybe it will be good to add `extern(CTFE)` too, so hdrgen=20
can emit source code for such functions to .di file. i.e.

`extern(none)` -- don't generate code, don't emit to .di
`extern(CTFE)` -- don't generate code, emit to .di
=
Apr 20 2015
prev sibling next sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 20.04.2015 um 15:22 schrieb Etienne:

 I've been using a lot of CTFE in my libraries and this has had the side
 effect of increasing my link time beyond 13 seconds. There's a pretty
 big chunk of those symbols being exported that are used only for
 evaluating mixins.

 Would there be a way to specify something in the lines of `extern
 (none):` or `intern:`?


Any reason why "private" couldn't be used for this? If a private 
function is only used for CTFE, there is no need to generate code at all.
Apr 20 2015
parent "Dicebot" <public dicebot.lv> writes:
On Monday, 20 April 2015 at 20:04:04 UTC, Sönke Ludwig wrote:

 Am 20.04.2015 um 15:22 schrieb Etienne:

 I've been using a lot of CTFE in my libraries and this has had 
 the side
 effect of increasing my link time beyond 13 seconds. There's a 
 pretty
 big chunk of those symbols being exported that are used only 
 for
 evaluating mixins.

 Would there be a way to specify something in the lines of 
 `extern
 (none):` or `intern:`?


 Any reason why "private" couldn't be used for this? If a 
 private function is only used for CTFE, there is no need to 
 generate code at all.


Need much more powerful flow analysis than DMD frontend is 
currently capable of. Specifically, it needs to ensure that this 
function is also not taken address of and not aliased via any of 
public templates (transitively), as well as not aliased to 
something available as public.
Apr 20 2015
prev sibling parent reply "extrawurst" <stephan extrawurst.org> writes:
On Monday, 20 April 2015 at 13:22:15 UTC, Etienne wrote:

 I've been using a lot of CTFE in my libraries and this has had 
 the side effect of increasing my link time beyond 13 seconds. 
 There's a pretty big chunk of those symbols being exported that 
 are used only for evaluating mixins.

 Would there be a way to specify something in the lines of 
 `extern (none):` or `intern:`?


what happens with totally empty functions ? can't they be removed 
on compilation ? static if(__ctfe){} could be used to make those 
empty for non-ctfe then..
Apr 20 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 20 Apr 2015 20:31:36 +0000, extrawurst wrote:


 static if(__ctfe){}


small fix: simply `if (__ctfe)`, `static if (__ctfe)` is error. ;-)=
Apr 20 2015
parent reply "extrawurst" <stephan extrawurst.org> writes:
On Monday, 20 April 2015 at 20:36:06 UTC, ketmar wrote:

 On Mon, 20 Apr 2015 20:31:36 +0000, extrawurst wrote:


 static if(__ctfe){}


 small fix: simply `if (__ctfe)`, `static if (__ctfe)` is error. 
 ;-)


__ctfe is not readable at compile time ? thats unfortunate..
Apr 20 2015
next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Mon, Apr 20, 2015 at 09:00:34PM +0000, extrawurst via Digitalmars-d wrote:

 On Monday, 20 April 2015 at 20:36:06 UTC, ketmar wrote:

On Mon, 20 Apr 2015 20:31:36 +0000, extrawurst wrote:


static if(__ctfe){}


small fix: simply `if (__ctfe)`, `static if (__ctfe)` is error. ;-)


 
 __ctfe is not readable at compile time ? thats unfortunate..


"Compile time" is actually a broad term that is not precise enough to
describe the distinction between template expansion / static if and
CTFE.

Basically, static if and template expansion happens at an earlier stage
of the compilation process -- conceptually speaking, somewhere between
parsing and semantic analysis. Perhaps one could think of it as AST
transformation prior to the AST being interpreted by the compiler. At
this stage, no semantic values (e.g., the state of variables, etc.) are
available, because the AST is not being interpreted yet.

CTFE, on the other hand, conceptually sits between semantic analysis and
code generation, which is at a later stage than the AST transformation
of templates / static if. Basically, at this point the AST is fixed and
the compiler is ready to emit object code, but instead of doing so, runs
it through an interpreter instead. So at this stage the compiler has
enough information to keep track of the values of variables and stuff,
and can simulate the effect of executing code at runtime. However, in
order for this simulation to have well-defined semantics, AST
transformations are no longer possible, so you cannot evaluate static
ifs in the CTFE stage.

This is why the __ctfe magic variable cannot be read at compile-time,
or, to be more precise, at AST transformation time. It can only be read
at CTFE-time.

Of course, this is a greatly simplified picture of how things actually
work in the compiler. The compiler isn't confined to a single AST
tranformation stage followed by a single CTFE stage; the whole point of
CTFE is that the result of the CTFE is fed back into the compiler to
influence AST transformation in another part of the code. This can be
done by running semantic analysis on the code to be CTFE-'d first, so
that it's ready for interpretation when another part of the code that
needs the CTFE value is still in the AST transformation stage.
Everything is eventually resolvable, as long as there are no circular
dependencies.

Nevertheless, the distinction between AST transformation and CTFE is an
important one (at least conceptually).  The function being CTFE'd must
be fully compiled before it can be CTFE'd (even if the rest of the code
isn't fully compiled yet), so static if must already be evaluated by the
time CTFE runs. Conversely, a static if / template expansion is by
definition not yet fully compiled, so it cannot evaluate references to
variables, even if said variables exist in CTFE (since CTFE hasn't
started yet at that point).


T

-- 
I'm still trying to find a pun for "punishment"...
Apr 20 2015
prev sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 20 Apr 2015 21:00:34 +0000, extrawurst wrote:


 On Monday, 20 April 2015 at 20:36:06 UTC, ketmar wrote:

 On Mon, 20 Apr 2015 20:31:36 +0000, extrawurst wrote:


 static if(__ctfe){}


 small fix: simply `if (__ctfe)`, `static if (__ctfe)` is error.
 ;-)


=20
 __ctfe is not readable at compile time ? thats unfortunate..


it will have no sense. DMD is able to eliminate dead code in this case,=20
so `if (__ctfe)` will generate plain function. and there is no sense in=20
do `static if` for functions, as functions is not instantiating, i.e.=20
that will be processed only once, and you will be unable to use function=20
both in CTFE and in run time.=
Apr 20 2015