Jump to page: 1 26  
Page
Thread overview
December 07
I'd like to add an attribute to indicate that the annotated function is only available at compile time so that in cases where the operation is invalid at runtime (strings and concatenation on a GPU for instance) but the result is only used at compile time (for a mixin) the compiler is free to not codegen that function.

I can add this to LDC pretty easily, but does anyone else have a use for this (e.g. shrinking binary sizes for mixin heavy codebases) and would benefit having this as a standard thing?
December 06
On Thu, Dec 07, 2017 at 01:21:11AM +0000, Nicholas Wilson via Digitalmars-d wrote:
> I'd like to add an attribute to indicate that the annotated function is only available at compile time so that in cases where the operation is invalid at runtime (strings and concatenation on a GPU for instance) but the result is only used at compile time (for a mixin) the compiler is free to not codegen that function.
> 
> I can add this to LDC pretty easily, but does anyone else have a use for this (e.g. shrinking binary sizes for mixin heavy codebases) and would benefit having this as a standard thing?

I'd like to have this too.  Some of my template-heavy code use a good number of CTFE-only functions that are only called at compile-time. Since they are nested inside the template, they do quickly add up to a lot of dead code in the executable.  Having a @ctfeonly annotation that tells the compiler not to codegen the (many instantiations of the) function would be greatly welcomed.


T

-- 
Let's eat some disquits while we format the biskettes.
December 07
On Thursday, 7 December 2017 at 01:21:11 UTC, Nicholas Wilson wrote:
> I'd like to add an attribute to indicate that the annotated function is only available at compile time so that in cases where the operation is invalid at runtime (strings and concatenation on a GPU for instance) but the result is only used at compile time (for a mixin) the compiler is free to not codegen that function.
>
> I can add this to LDC pretty easily, but does anyone else have a use for this (e.g. shrinking binary sizes for mixin heavy codebases) and would benefit having this as a standard thing?

Shouldn't the linker do this already?

Once the compiler has CTFE'd the function any call in the code should be replaced with the function evaluation. The linker should then drop the code out of the binary because it really is dead code.

bye,
lobo
December 07
H. S. Teoh wrote:

> On Thu, Dec 07, 2017 at 01:21:11AM +0000, Nicholas Wilson via Digitalmars-d wrote:
>> I'd like to add an attribute to indicate that the annotated function
>> is only available at compile time so that in cases where the operation
>> is invalid at runtime (strings and concatenation on a GPU for
>> instance) but the result is only used at compile time (for a mixin)
>> the compiler is free to not codegen that function.
>> I can add this to LDC pretty easily, but does anyone else have a use
>> for this (e.g. shrinking binary sizes for mixin heavy codebases) and
>> would benefit having this as a standard thing?
>
> I'd like to have this too.  Some of my template-heavy code use a good
> number of CTFE-only functions that are only called at compile-time.
> Since they are nested inside the template, they do quickly add up to a
> lot of dead code in the executable.  Having a @ctfeonly annotation that
> tells the compiler not to codegen the (many instantiations of the)
> function would be greatly welcomed.
>
>
> T

this is a hack for something that really should be done in linker, automatically. please, people, let's not turn D into C++! ;-)

i mean: this has a short-time benefits, but makes the language more complex, less clear, and completely destroys any incentive to make smartlinking work as intended in case it is broken.
December 06
On Thursday, December 07, 2017 02:09:56 lobo via Digitalmars-d wrote:
> On Thursday, 7 December 2017 at 01:21:11 UTC, Nicholas Wilson
>
> wrote:
> > I'd like to add an attribute to indicate that the annotated function is only available at compile time so that in cases where the operation is invalid at runtime (strings and concatenation on a GPU for instance) but the result is only used at compile time (for a mixin) the compiler is free to not codegen that function.
> >
> > I can add this to LDC pretty easily, but does anyone else have a use for this (e.g. shrinking binary sizes for mixin heavy codebases) and would benefit having this as a standard thing?
>
> Shouldn't the linker do this already?
>
> Once the compiler has CTFE'd the function any call in the code should be replaced with the function evaluation. The linker should then drop the code out of the binary because it really is dead code.

As I understand it, if you're statically linking it should, but it can't with dynamic linking - at least not right now. With the export improvements that Martin Nowak and Benjamin Thaut want to do (where IIUC, export would then be required for anything in a shared library to be accessible outside it), then it would be possible, but right now, everything gets exported (at least on all systems other than Windows), so none of it can be stripped out as unused, since the linker doesn't know what's actually going to be used. Executables should be in the same boat as static libraries though.

Also, I think that in some cases, stuff like ModuleInfo ends up referring to stuff and keeping it around even though it isn't necessarily really used, but I'm not sure.

Folks have talked about all kinds of template code and stuff being kept around in binaries even though it was only used at compile time (e.g. stuff like isInputRange), but I don't know how much that's actually true. Personally, I don't care much about binary sizes. I certainly agree that having unused symbols stripped out where possible is a good thing, but AFAIK, it doesn't really matter for most of the stuff I do, and having a binary be 5MiB instead of 1MiB doesn't matter much to me, much as I agree that having the binary smaller is good. It just isn't usually enough disk space or memory to matter much in practice. Clearly, some people care quite a bit about that sort of thing, but I don't know how much it actually matters in practice unless you're doing something with embedded systems.

Regardless, needing something like an attribute to tell the compiler to strip stuff out of the binary seems like a hack to me. It may actually be necessary in some cases, but it just feels like it should be unnecessary.

- Jonathan M Davis

December 07
On Thursday, 7 December 2017 at 02:33:49 UTC, ketmar wrote:
> H. S. Teoh wrote:
>
>> On Thu, Dec 07, 2017 at 01:21:11AM +0000, Nicholas Wilson via Digitalmars-d wrote:
>>> [...]
>>
>> I'd like to have this too.  Some of my template-heavy code use a good
>> number of CTFE-only functions that are only called at compile-time.
>> Since they are nested inside the template, they do quickly add up to a
>> lot of dead code in the executable.  Having a @ctfeonly annotation that
>> tells the compiler not to codegen the (many instantiations of the)
>> function would be greatly welcomed.
>>
>>
>> T
>
> this is a hack for something that really should be done in linker, automatically. please, people, let's not turn D into C++! ;-)
>
> i mean: this has a short-time benefits, but makes the language more complex, less clear, and completely destroys any incentive to make smartlinking work as intended in case it is broken.

Not all of the generated code goes through a linker ;)
For dcompute strings aren't even supported yet! Let alone concatenation.

Also not generating the code in the first place means less I/O for the compiler and less work for the linker.

I definitely don't want D to become C++. What is smartlinking?

This is intended for stuff like code that generates strings for mixins.
December 07
On Thursday, 7 December 2017 at 03:18:57 UTC, Jonathan M Davis wrote:
> On Thursday, December 07, 2017 02:09:56 lobo via Digitalmars-d wrote:
>> On Thursday, 7 December 2017 at 01:21:11 UTC, Nicholas Wilson
>>
>> wrote:
>> > I'd like to add an attribute to indicate that the annotated function is only available at compile time so that in cases where the operation is invalid at runtime (strings and concatenation on a GPU for instance) but the result is only used at compile time (for a mixin) the compiler is free to not codegen that function.
>> >
>> > I can add this to LDC pretty easily, but does anyone else have a use for this (e.g. shrinking binary sizes for mixin heavy codebases) and would benefit having this as a standard thing?
>>
>> Shouldn't the linker do this already?
>>
>> Once the compiler has CTFE'd the function any call in the code should be replaced with the function evaluation. The linker should then drop the code out of the binary because it really is dead code.
>

Unfortunately I don't have a linker to do that for me with DCompute.

> Regardless, needing something like an attribute to tell the compiler to strip stuff out of the binary seems like a hack to me. It may actually be necessary in some cases, but it just feels like it should be unnecessary.

Do you have any other ideas about how to achieve this other than an attribute?
Having an attribute seems the most simple and straightforward.

December 07
Nicholas Wilson wrote:

> Also not generating the code in the first place means less I/O for the compiler and less work for the linker.
this is solvable without any additional flags, tho: compiler should just skip codegen phase for any function that is not referenced by another compiled function (except for library case).


> I definitely don't want D to become C++. What is smartlinking?
any decent linker simply drops anything that is not reveferenced. i.e. any function that is not referenced from another function that is definitely included in the binary, will be skipped. as linker knows program entry point, it is able to build reference tree, and do "smart" linking instead of just putting everything into resulting binary.


> This is intended for stuff like code that generates strings for mixins.
as i said, this is something compiler can do automatically, without user's help. we already have too much attributes, i believe, adding even more won't do any good.
December 07
ketmar wrote:

> Nicholas Wilson wrote:
>
>> Also not generating the code in the first place means less I/O for the compiler and less work for the linker.
> this is solvable without any additional flags, tho: compiler should just skip codegen phase for any function that is not referenced by another compiled function (except for library case).

p.s.: actually, dmd already creates .a files suitable for smartlinking (otherwise any binary would include the whole libphobos2.a ;-). but for "dmd mycode.d" dmd doesn't do this ('cause it is quite compilcated for non-library case). the whole issue prolly can be solved by "generate smart object files for linking" flag (which will create .a files for everything, so linker can do it's smart work).
December 07
On Thursday, 7 December 2017 at 01:21:11 UTC, Nicholas Wilson wrote:

> I can add this to LDC pretty easily, but does anyone else have a use for this (e.g. shrinking binary sizes for mixin heavy codebases) and would benefit having this as a standard thing?

I've thought about this in the past, but never really pursued it much to see if there are already existing facilities in the language to accomplish what I want.

I want to enforce that a method is only used at compile time.  That is I want either the compiler or the linker to throw an error if I've accidentally used a function at runtime when I only intended it to be used at compile-time.  Also, I want the compiler to let me know if my intended-for-compile-time-only function cannot be used at compile-time because I mistakenly made it dependent on something that is only available at runtime.

That being said, I want D's features to carry their weight.  I would first like to prove that facilities don't already exist or that existing facilities are too cumbersome to accomplish said goal before adding such a feature.

Also, my primary motivation for using D is so I can program resource-constrained microcontrollers in a more fun and convenient language than C/C++.  I've definitely encountered code-size problems in D, but they were mostly due to the compiler's unnecessary coupling to the runtime, and the way the compiler generated code as the linker couldn't prove that the code was dead (Exhibit A: https://issues.dlang.org/show_bug.cgi?id=14758).  I don't yet see how @ctfeonly would help with that.

Mike
« First   ‹ Prev
1 2 3 4 5 6