Hi Guys,

I am currently working on speeding up dmd. In the presence of templates and ctfe.
and one thing that stood out is that we do codegen for symbols which are never used.
(and hopefully eliminated by a smart linker but eh ...)

I've seen the following pattern in the wild.


string GenerateMixin(string[] params)
{
    assert(__ctfe);
    .... more code ....
}

that means if we see assert(__ctfe) inside the outermost scope of a function body ( not in a branch) then we know that this function would assert if called at runtime.
And therefore no correct code can be calling it.
which also means we can forgo having code-gen or optimization for the function body.
and reduce the count of names which has to get mangled.

They only downside to this, is that giving assert(__ctfe) the special meaning to skip codegen might be confusing to some people .... then again you wouldn't use assert(__ctfe) unless you expect that function to not be available at run-time

What do you guys think?

Cheers,

Stefan

On Sunday, 5 April 2020 at 12:11:23 UTC, Stefan Koch wrote:
> Hi Guys,
> ....
> What do you guys think?
>

One more thing.
The implementation of this is not that hard, and almost done already.
(just in case you're getting trigger happy Walter. )

On Sunday, 5 April 2020 at 12:11:23 UTC, Stefan Koch wrote:
> Hi Guys,
> ....
> What do you guys think?
>

I had a similar thought some time ago:
https://github.com/dlang/DIPs/pull/177#issuecomment-539894029

;)

On Sunday, 5 April 2020 at 12:11:23 UTC, Stefan Koch wrote:
> What do you guys think?

good enough for me.

On Sunday, 5 April 2020 at 12:11:23 UTC, Stefan Koch wrote:
> Hi Guys,
>
> [...]
>
> What do you guys think?
>
> Cheers,
>
> Stefan

I'd prefer a new func attribute `@ctfe`.
Also I find the current implementation unplesant. Cant you just check the assertion when they are already visited elsewhere e.g in dmd.expressionsem.ExpressionSemanticVisitor.visit(AssertExp) ? Also what if we are in a contract ?

On Sunday, 5 April 2020 at 12:11:23 UTC, Stefan Koch wrote:
> They only downside to this, is that giving assert(__ctfe) the special meaning to skip codegen might be confusing to some people .... then again you wouldn't use assert(__ctfe) unless you expect that function to not be available at run-time
>
> What do you guys think?

Ideally it should only skip codegen if there are no statements with side-effects before the assert(__ctfe). However, I think it's fine to do it your way if that's easier to implement in the compiler, as long as normal code gen and optimization is still enabled for functions containing this construct, as a workaround:

if(!__ctfe) assert(0);

On Sunday, 5 April 2020 at 13:54:19 UTC, tsbockman wrote:
> On Sunday, 5 April 2020 at 12:11:23 UTC, Stefan Koch wrote:
>> They only downside to this, is that giving assert(__ctfe) the special meaning to skip codegen might be confusing to some people .... then again you wouldn't use assert(__ctfe) unless you expect that function to not be available at run-time
>>
>> What do you guys think?
>
> Ideally it should only skip codegen if there are no statements with side-effects before the assert(__ctfe). However, I think it's fine to do it your way if that's easier to implement in the compiler, as long as normal code gen and optimization is still enabled for functions containing this construct, as a workaround:
>
> if(!__ctfe) assert(0);

So it's much easier to just scan for assert(__ctfe);

I've just implemented it and the projects on the dlang buildkite are green.

On Sunday, 5 April 2020 at 13:26:22 UTC, Basile B. wrote:
> On Sunday, 5 April 2020 at 12:11:23 UTC, Stefan Koch wrote:
>> Hi Guys,
>>
>> [...]
>>
>> What do you guys think?
>>
>> Cheers,
>>
>> Stefan
>
> I'd prefer a new func attribute `@ctfe`.
> Also I find the current implementation unplesant. Cant you just check the assertion when they are already visited elsewhere e.g in dmd.expressionsem.ExpressionSemanticVisitor.visit(AssertExp) ? Also what if we are in a contract ?

Don't we have enough attributes already?

I _could_ but then it's hard to know if I am in the top-level of the function body.

On Sunday, 5 April 2020 at 14:04:12 UTC, Stefan Koch wrote:
> On Sunday, 5 April 2020 at 13:26:22 UTC, Basile B. wrote:
>> On Sunday, 5 April 2020 at 12:11:23 UTC, Stefan Koch wrote:
>>> Hi Guys,
>>>
>>> [...]
>>>
>>> What do you guys think?
>>>
>>> Cheers,
>>>
>>> Stefan
>>
>> I'd prefer a new func attribute `@ctfe`.
>> Also I find the current implementation unplesant. Cant you just check the assertion when they are already visited elsewhere e.g in dmd.expressionsem.ExpressionSemanticVisitor.visit(AssertExp) ? Also what if we are in a contract ?
>
> Don't we have enough attributes already?

I don't know. The criticism I have aginst func attributes is more that their style are mixed (i.e w/ or w/o '@'). Anyway I'm not strongly against your way, it's just that in a perfect world I imagine @ctfe rather.

On 4/5/20 8:11 AM, Stefan Koch wrote:
> What do you guys think?

It seems like a good idea, except what you will see is a linker error if you call it. Which is not very friendly or gives the right impression.

Is there a way we can have the compiler give an error when it sees this during compile-time?

-Steve