Lack of optimisation with returning address of inner functions

[Adam D. Ruppe]

On Friday, 4 September 2020 at 01:10:48 UTC, Cecil Ward wrote:
> 1. So why the lack of optimisation? - could simply have got rid 
> of the delegate generation in test2a as implementations when it 
> is inlined in bar (and which is done sanely [!] in the 
> generated code for test2a).

I think this is a frontend/backend thing.

That optimization is done by the back end, but the front end 
doesn't know that and still assumes there's a full-blown delegate 
required.

> 2. Even weirder, if you delete the & from &foo leaving simply 
> "return foo;" then this fixes the non-optimisation bug. Why?

That just calls the function and returns its value, which 
obviously needs no delegate since the function doesn't outlive 
the surrounding context.

> 3. What’s the difference between foo and &foo ?

Huge, huge difference.

&foo returns a function pointer or delegate referring to the 
function. The function is not called here.

foo is just foo() without the optional parenthesis; the function 
is actually immediately called.

Whenever the compiler frontend sees a `return 
&some_nested_function` it assumes a longer lifetime is required 
and allocates the captured variables on the heap up front.

So by the time it gets to the optimizer in the back end, it sees 
all that allocation and pointer code already existing. With 
certain settings, it might be able to see through it and optimize 
anyway, but its job got a lot harder since it might not know what 
happens with that return value later in the program.

I suspect the best you'd see in practice is all usages get 
inlined then the linker can discard the actual function that 
allocates as unused but even that can be harder than it seems for 
the backend to figure out given the information it has. It 
doesn't really understand *why* it is calling this other 
function, it just knows it is.