DMD and GDC are unnecessarily using heap allocations for closures

[max haughton]

On Monday, 30 May 2022 at 10:41:10 UTC, Johan wrote:
> 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

Ideally the dmd frontend would have a nice reliable IR to do this 
analysis properly and then have a more aggressive notion of 
@nogc, but it doesn't unfortunately.

SDC does have an IR but it's a long way away from being able to 
worry about this kind of issue. Hypothetically it would be much 
more feasible to drop into an IR where you can do dataflow 
analysis properly then go back to an AST.

Also, the semantics can be specified as a set of test cases any D 
compiler must be able to resolve without closures. That way you 
can rely on it but don't have to force the implementations to do 
a certain thing (other than doing something at all).

I did fiddle around with getting GCC to do this but I'm not sure 
it can be done without breaking a sweat.