Skip to content
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

cmd/compile: unify and improve struct/array equality comparisons #38674

Closed
josharian opened this issue Apr 26, 2020 · 0 comments
Closed

cmd/compile: unify and improve struct/array equality comparisons #38674

josharian opened this issue Apr 26, 2020 · 0 comments
Labels
FrozenDueToAge help wanted NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Performance
Milestone

Comments

@josharian
Copy link
Contributor

We have completely separate paths to generate code to compare (=, !=) small structs/arrays and large structs/arrays. The small ones get inlined and happen in walk.go. The large ones get converted to a function call and happen in alg.go. (The small ones also get a function call generated, for use by maps.)

These separate code paths were fine when they they were fairly simple. However, I recently put some work into generating better eq alg routines (CLs 230203-230210). The inline comparisons could use some of the same optimizations, particularly better condition ordering.

And if we pulled both the code generation for small structs/arrays and the decision point for inlining into a re-usable function, we could do an even better job of generating code. Currently, the alg generation routines must treat structs as opaque. If we could break them apart into pieces, the way we (will soon) handle strings, we could profitably re-order their conditions as well. This would also help with #38494.

The proposal here is to do refactor out a unified code generation routine for comparing arrays and structs, much like CL 230204 and CL 230206 do for strings and interfaces, although more complicated. Then unify the implementation with geneq in alg.go. Then use that implementation recursively to generate better code.

This is probably accessible for someone with a bit of experience with the compiler, and some patience, so marking help wanted. I have no concrete plans to work on it at the moment.

@josharian josharian added this to the Unplanned milestone Apr 26, 2020
@andybons andybons added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Apr 27, 2020
derekparker added a commit to derekparker/go that referenced this issue Apr 12, 2022
@golang golang locked and limited conversation to collaborators Apr 21, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge help wanted NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Performance
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants