Was thinking about this, see https://issues.dlang.org/show_bug.cgi?id=21065.

One problem I noticed with the current instrumentation of allocations is that it is extremely slow. https://github.com/dlang/dmd/pull/11381 takes care of that trivially and quickly because it takes advantage of defining one static variable per instantiation.

Two thoughts on the subject:

1) it should probably always be inlined so it doesn't make new symbols in codegen.

2) the compiler should be free to cheat a little for optimization; if it can see the var never escapes, it might even still pop it on the stack (perhaps the function receives a pointer to the memory and if null, it is responsible for allocing it). This may not be implemented but the spec should at least be written to allow it later. This kind of optimization can be a real winner with scope too.

On Thu, Jul 23, 2020 at 10:50 AM Andrei Alexandrescu via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> Was thinking about this, see https://issues.dlang.org/show_bug.cgi?id=21065.
>
> One problem I noticed with the current instrumentation of allocations is that it is extremely slow. https://github.com/dlang/dmd/pull/11381 takes care of that trivially and quickly because it takes advantage of defining one static variable per instantiation.
>

I've had this thought too. Great idea!

On 7/22/2020 6:05 PM, Adam D. Ruppe wrote:
> 2) the compiler should be free to cheat a little for optimization; if it can see the var never escapes, it might even still pop it on the stack (perhaps the function receives a pointer to the memory and if null, it is responsible for allocing it). This may not be implemented but the spec should at least be written to allow it later. This kind of optimization can be a real winner with scope too.

The compiler already does this if the variable being new`d is `scope`.

On Thursday, 23 July 2020 at 05:12:30 UTC, Walter Bright wrote:
> On 7/22/2020 6:05 PM, Adam D. Ruppe wrote:
>> 2) the compiler should be free to cheat a little for optimization; if it can see the var never escapes, it might even still pop it on the stack (perhaps the function receives a pointer to the memory and if null, it is responsible for allocing it). This may not be implemented but the spec should at least be written to allow it later. This kind of optimization can be a real winner with scope too.
>
> The compiler already does this if the variable being new`d is `scope`.

LDC has an optimization pass [1] which promotes heap allocations to stack allocations, without  the user having to manually use the `scope` storage class for function-local variables.
Do you think we could formalize this optimization and move it up the pipeline into the front-end, so that it's guaranteed to be performed by all 3 compilers?

[1]: https://github.com/ldc-developers/ldc/blob/v1.23.0-beta1/gen/passes/GarbageCollect2Stack.cpp

On Thursday, 23 July 2020 at 06:13:52 UTC, Petar Kirov [ZombineDev] wrote:
> On Thursday, 23 July 2020 at 05:12:30 UTC, Walter Bright wrote:
>> On 7/22/2020 6:05 PM, Adam D. Ruppe wrote:
>>> [...]
>>
>> The compiler already does this if the variable being new`d is `scope`.
>
> LDC has an optimization pass [1] which promotes heap allocations to stack allocations, without  the user having to manually use the `scope` storage class for function-local variables.
> Do you think we could formalize this optimization and move it up the pipeline into the front-end, so that it's guaranteed to be performed by all 3 compilers?
>
> [1]: https://github.com/ldc-developers/ldc/blob/v1.23.0-beta1/gen/passes/GarbageCollect2Stack.cpp

... building upon the infrastructure in src/dmd/escape.d

On 7/22/2020 11:13 PM, Petar Kirov [ZombineDev] wrote:
>> The compiler already does this if the variable being new`d is `scope`.
> 
> LDC has an optimization pass [1] which promotes heap allocations to stack allocations, without  the user having to manually use the `scope` storage class for function-local variables.
> Do you think we could formalize this optimization and move it up the pipeline into the front-end, so that it's guaranteed to be performed by all 3 compilers?
> 
> [1]: https://github.com/ldc-developers/ldc/blob/v1.23.0-beta1/gen/passes/GarbageCollect2Stack.cpp 

It's a good idea, but I'd consider it a low priority since it is so easy to add scope.

As for guaranteeing stack placement in the language spec, it's usually regarded as being in the QoI (Quality of Implementation) domain.

On Thursday, 23 July 2020 at 10:08:08 UTC, Walter Bright wrote:
> On 7/22/2020 11:13 PM, Petar Kirov [ZombineDev] wrote:
>>> The compiler already does this if the variable being new`d is `scope`.
>> 
>> LDC has an optimization pass [1] which promotes heap allocations to stack allocations, without  the user having to manually use the `scope` storage class for function-local variables.
>> Do you think we could formalize this optimization and move it up the pipeline into the front-end, so that it's guaranteed to be performed by all 3 compilers?
>> 
>> [1]: https://github.com/ldc-developers/ldc/blob/v1.23.0-beta1/gen/passes/GarbageCollect2Stack.cpp
>
> It's a good idea, but I'd consider it a low priority since it is so easy to add scope.
>
> As for guaranteeing stack placement in the language spec, it's usually regarded as being in the QoI (Quality of Implementation) domain.

I agree that it's not a high priority. Migrating more druntime hook to templates is more impactful as it unlocks various opportunities, whereas an optimization like this has a relatively fixed improvement potential.

On Thursday, 23 July 2020 at 05:12:30 UTC, Walter Bright wrote:
> The compiler already does this if the variable being new`d is `scope`.

Interesting.

BTW:

1. could such `scope`d new's be allocated on a thread-local heap (instead of the global GC heap) thereby eliding the costly spinlock in the current GC implementation, given that we provide a separate lock-less interface in the GC for scoped allocations? That would make new's even faster for small sizes.

2. how could this `scope`-qualification of `new`s be inferred by the compiler using escape analysis of the `new`-ed variable? Do you any plans on implementing this for the simple cases, Walter? If it's costly could be activated in release mode?

On Thursday, 23 July 2020 at 10:19:41 UTC, Petar Kirov [ZombineDev] wrote:
>> It's a good idea, but I'd consider it a low priority since it is so easy to add scope.
>>
>> As for guaranteeing stack placement in the language spec, it's usually regarded as being in the QoI (Quality of Implementation) domain.
>
> I agree that it's not a high priority. Migrating more druntime hook to templates is more impactful as it unlocks various opportunities, whereas an optimization like this has a relatively fixed improvement potential.

I actually see 3 (instead of 2) kinds of allocations here:

1. GC: destruction during `GC.collect()`
2. C/C++-style heap: (too large to fit on stack) scoped destruction (could be inferred?)
3. Stack: scoped destruction (inferred by LDC)

The 2. is not being discussed here. Is this case obvious or irrelevant? If not which part of the runtime should handle such allocations? The GC?