/cc @mdempsky

(I'm assuming that in your actual application the ok := true is something that's actually not statically predictable. That is, that your issue is more than you think we should apply better dead code elimination here.)

In BadOperation, the call to caller.Address() means that caller might escape to the heap (because we're invoking an interface method, and we don't know what that method does with the receiver). So the Account{} in AccountRef(Account{}) has to be heap allocated because of this. I don't think there's anything we can do about this.

The contract.CodeAddr = &addr part is a bit subtler, and there's arguably room for improvement. There's two related issues here:

1. Here contract is a pointer, so contract.CodeAddr = ... is an assignment through a pointer, so we conservatively treat it as a store to the heap. You can avoid this by changing contract := &Contract{...} to contract := Contract{...}.

   Theoretically escape analysis could recognize that the pointer is actually always pointing to a composite literal. This would be easier to do on SSA, but there's basic patterns like this we could recognize even in the Node AST.

2. The other aspect is that if the address of a local variable leaks anywhere (even in a path we don't take), we conservatively allocate the object on the heap. We could theoretically move the object to the heap only once we know it escapes, but that has its own complexities.

That is, that your issue is more than you think we should apply better dead code elimination here.

Yes, exactly!

Thanks for the detailed explanation! It helped me to figure out how to work around this -- in this case, I took a copy of the addr so that the pointer reference does not leak. ethereum/go-ethereum@e02eb02#diff-1ad751e400b74d9c7234ae3134edccf0R359 .

Three pretty small changes (three commits ending with that one) reduced the allocations dramatically.

As far as I'm concerned, this ticket can be closed (unless you want it to remain open since " there's arguably room for improvement")

Change https://golang.org/cl/262937 mentions this issue: cmd/compile: handle escape analysis assignment through pointer more precisely

@cuonglm found a fix for this in CL 262937, but it appears to not help real world Go code much. E.g., k8s.io/kubernetes/cmd/kubelet is only able to stack allocate one new variable.

Right now, the staticValue optimization it relies on is less efficient than it could be (it already showed up as a measurable compiler performance hit in fixing #41474). I'm thinking we should optimize that first. Once the fix doesn't impact compile-time, I'm okay with revisiting the optimization.