December 07, 2017
On Thursday, 7 December 2017 at 03:43:42 UTC, Nicholas Wilson wrote:
> ...
>
> Do you have any other ideas about how to achieve this other than an attribute?
> Having an attribute seems the most simple and straightforward.

llvm has "Aggressive Dead Code Elimination"- and "Dead Code Elimination"-switches, who I find interesting.
https://llvm.org/docs/Passes.html#transform-passes

I remember once I actually stripped off kinda 99% of a statically linked phobos-library with that and I got a small executable who was still working
December 06, 2017
On Thursday, December 07, 2017 03:59:09 Mike Franklin via Digitalmars-d wrote:
> 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.

The simplest way to do that is to write a unit test that uses a static assertion. As I understand it, with the way CTFE works, it pretty much can't know whether a function can be called at compile time until it tries, but a unit test can catch it if the function no longer works at compile time.

- Jonathan M Davis

December 06, 2017
On Thursday, December 07, 2017 03:43:42 Nicholas Wilson via Digitalmars-d wrote:
> 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.

It may be that an attribute is required in at least some cases, but it seems like it shouldn't be and that if the compiler and/or linker isn't smart enough to strip out stuff that's only used at compile time, then it should be fixed to be smart enough. However, too often, there's some detail that's not obvious that makes it so that things can't work they way that it seems like they should. And of course, I have no clue how whatever you're doing works if you're not using a linker with dcompute, so I don't know how it differs from normal. I've never done anything with GPU programming.

- Jonathan M Davis

December 07, 2017
On Thursday, 7 December 2017 at 04:45:15 UTC, Jonathan M Davis wrote:
As I understand it, with the way CTFE works,
> it pretty much can't know whether a function can be called at compile time until it tries
>
> - Jonathan M Davis

I think that's the point of the attribute. You tell the compiler that this function can only be called at compile-time and any attempt to call it during run-time would be an error.

December 07, 2017
On Thursday, 7 December 2017 at 05:53:06 UTC, bauss wrote:
> On Thursday, 7 December 2017 at 04:45:15 UTC, Jonathan M Davis wrote:
> As I understand it, with the way CTFE works,
>> it pretty much can't know whether a function can be called at compile time until it tries
>>
>> - Jonathan M Davis
>
> I think that's the point of the attribute. You tell the compiler that this function can only be called at compile-time and any attempt to call it during run-time would be an error.

If all you need is a runtime error, you can already put assert(__ctfe); in your function.
December 07, 2017
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?

Hi Nicholas,

I am going to add a feature which will help you in this case;
As part of the work I am doing to make templates faster.


December 07, 2017
On Thursday, 7 December 2017 at 04:45:15 UTC, Jonathan M Davis wrote:

> The simplest way to do that is to write a unit test that uses a static assertion. As I understand it, with the way CTFE works, it pretty much can't know whether a function can be called at compile time until it tries, but a unit test can catch it if the function no longer works at compile time.

Not bad, but that is swaying into the cumbersome category.  If that's the best we can do, a @ctfeonly attribute starts looking pretty good.

Mike


December 07, 2017
On Thursday, 7 December 2017 at 06:33:42 UTC, E.S. Quinn wrote:

> If all you need is a runtime error, you can already put assert(__ctfe); in your function.

For me, a runtime error is exactly what I want to avoid.

Mike
December 07, 2017
On Thursday, December 07, 2017 07:41:18 Mike Franklin via Digitalmars-d wrote:
> On Thursday, 7 December 2017 at 04:45:15 UTC, Jonathan M Davis
>
> wrote:
> > The simplest way to do that is to write a unit test that uses a static assertion. As I understand it, with the way CTFE works, it pretty much can't know whether a function can be called at compile time until it tries, but a unit test can catch it if the function no longer works at compile time.
>
> Not bad, but that is swaying into the cumbersome category.  If that's the best we can do, a @ctfeonly attribute starts looking pretty good.

In the vast majority of cases, when a function is used for CTFE, it's also used during runtime. So, in most cases, you want to ensure that a function works both with CTFE and without, and in those cases something like @ctfeonly wouldn't make any sense. In my experience, pretty much the only time that something like @ctfeonly would make any sense would be with a function for generating a string mixin. I'm sure that there are folks who have other uses for functions that would only be used during CTFE, but really, CTFE is designed with the idea that functions would be useable both at runtime and at compile time, and most functions that are used during CTFE were not designed just for CTFE. Certainly, trying to test or enforce that a function is only used at compile time is not going to be the common case.

- Jonathan M Davis

December 07, 2017
On 12/6/2017 5:21 PM, 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.

Put these functions into a separate import. Then import the file and use the functions at compile time. They will not have code generated for them.