DMD and GDC are unnecessarily using heap allocations for closures

[Johan]

On Monday, 30 May 2022 at 10:24:12 UTC, Siarhei Siamashka wrote:
> On Monday, 30 May 2022 at 07:42:29 UTC, user1234 wrote:
>> maybe `private long binary_search(long n, long val, long 
>> i){...}` will make think other compilers that the stuff is 
>> only used localy ?
>
> The code can be massaged in various ways to reduce the 
> allocation overhead. For example, the whole 'binary_search' 
> function is not necessary and the code from it can be manually 
> inlined (this reduces the allocation penalty).
>
> So far I'm quite happy about the quality of the code generated 
> by LDC and it has never failed me. But I wonder if the @nogc 
> attribute can play a bit nicer with the GC2Stack IR 
> optimization pass? For example, somehow postpone the error 
> reporting in the frontend and only fail if GC2Stack is actually 
> unable to eliminate all GC allocations in the @nogc code. Maybe 
> I can report this to LDC developers.

The `@nogc` attribute is a language-level guarantee that no GC 
allocations will happen in that function. This guarantee can not 
depend on an optimization, unless any compiler implementation is 
required to implement that optimization also for unoptimized 
code: effectively making it no longer an "optimization", but just 
normal language behavior. (example: C++17 requires copy elision 
when a function returns a temporary object+ (unnamed object), but 
does not require it when a function returns a named object.)

In short: what you propose for LDC should not be done.

-Johan