Skip to content

cmd/compile: avoid allocs by better tracking of literals for interface conversions and make #71359

Closed
@thepudds

Description

@thepudds

In this example, converting a concrete value to an interface does not cause the integer value to be heap allocated:

fmt.Println(1000) 

For that example, escape analysis currently marks the value as escaping to the heap due to the interface conversion and the call to fmt.Println (and all that happens inside Println), but walk later recognizes the value does not need to be heap allocated.

On the other hand, the integer value in the following interface conversion does get heap allocated because the optimization in walk is thwarted by the literal getting assigned to a local variable prior to use in the interface conversion:

v := 1000
fmt.Println(v) 

We should be able to recognize this and get a similar result with those two cases. (This would be a follow up to Josh's work in #18704).

Separately, this slice can be stack allocated with a constant size (if it doesn't otherwise escape):

s := make([]int, 100)

But this slice is heap allocated because escape analysis treats it as having a non-constant size:

count := 100
s := make([]int, count)

We also should be able to recognize this.

The above scenarios might happen in a single function, but can also be the result of inlining one function into another.

We can hopefully handle this early in the compiler after inlining and devirtualization but before finalizing escape analysis results. Part of the solution can be using the new-ish ir.ReassignOracle.


I have a rough proof-of-concept that seems to hopefully handle cases similar to the ones above for basic literals and I plan to send a couple of CLs. The approach likely could be extended further. (I noticed this a while ago when working on #62653; there is some overlap with cases handled between that issue and this issue, though #62653 would be the broader solution for interface conversions).

Activity

self-assigned this
on Jan 21, 2025
added
BugReportIssues describing a possible bug in the Go implementation.
on Jan 21, 2025
added this to the Unplanned milestone on Jan 29, 2025
gopherbot

gopherbot commented on Feb 13, 2025

@gopherbot
Contributor

Change https://go.dev/cl/649077 mentions this issue: cmd/compile/internal/escape: propagate constants to make arguments

gopherbot

gopherbot commented on Feb 13, 2025

@gopherbot
Contributor

Change https://go.dev/cl/649076 mentions this issue: cmd/compile/internal/escape: additional constant and zero-value tests plus debug logging

gopherbot

gopherbot commented on Feb 13, 2025

@gopherbot
Contributor

Change https://go.dev/cl/649079 mentions this issue: cmd/compile/internal/escape: propagate constants to interface conversion arguments

gopherbot

gopherbot commented on Feb 18, 2025

@gopherbot
Contributor

Change https://go.dev/cl/649555 mentions this issue: cmd/compile/internal/walk: convert composite literals to interfaces without allocating

gopherbot

gopherbot commented on Mar 2, 2025

@gopherbot
Contributor

Change https://go.dev/cl/649078 mentions this issue: cmd/compile/internal/walk: use global zeroVal in interface conversions for zero values

15 remaining items

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

BugReportIssues describing a possible bug in the Go implementation.Performancecompiler/runtimeIssues related to the Go compiler and/or runtime.

Type

No type

Projects

Status

Done

Relationships

None yet

    Development

    No branches or pull requests

      Participants

      @mknyszek@gopherbot@thepudds@gabyhelp

      Issue actions

        cmd/compile: avoid allocs by better tracking of literals for interface conversions and make · Issue #71359 · golang/go