Skip to content

cmd/compile: sometimes issue rematerializable values early #24930

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
josharian opened this issue Apr 18, 2018 · 0 comments
Open

cmd/compile: sometimes issue rematerializable values early #24930

josharian opened this issue Apr 18, 2018 · 0 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. Performance
Milestone

Comments

@josharian
Copy link
Contributor

package p

var (
	s *int
	b bool
)

func f() {
	var q *int
	if b {
		q = new(int)
	} else {
		q = new(int)
	}
	s = q
}

This code is a bit silly, but it's the smallest reproduction I have handy. :)

When compiled, this code tests b, and on each branch it contains an LEAQ of type.int. The LEAQ should be hoisted above the branch, since it is needed immediately in each case, and there are registers to spare.

The CSE pass does its work, and there is a single LEAQ instruction going into regalloc. However, early in regalloc, we decide to issue it every place we need it:

			if s.values[v.ID].rematerializeable {
				// Value is rematerializeable, don't issue it here.
				// It will get issued just before each use (see
				// allocValueToReg).
				for _, a := range v.Args {
					a.Uses--
				}
				s.advanceUses(v)
				continue
			}

This is usually the right decision--disabling this bit of code causes an overall regression. But as the initial code shows, there are instances in which it'd be better to issue the rematerializable value right away. I'm not sure exactly what the right set of conditions is, though.

cc @cherrymui @randall77

@josharian josharian added this to the Unplanned milestone Apr 18, 2018
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. Performance
Projects
None yet
Development

No branches or pull requests

2 participants