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

Jump to bottom

cmd/compile: generic optimizations cannot remove load-hit-store on struct field #19164

Closed
mundaym opened this issue Feb 17, 2017 · 3 comments
Closed

cmd/compile: generic optimizations cannot remove load-hit-store on struct field #19164

mundaym opened this issue Feb 17, 2017 · 3 comments
Labels
FrozenDueToAge Performance

Comments

@mundaym
Copy link
Member

mundaym commented Feb 17, 2017 •
edited

On tip (ddb15ce) it looks like there is an opportunity for the generic optimizations to remove a load-hit-store of struct fields. They can't currently because for some reason the types of OffPtr are different for loads and stores. For example:

type t struct {
        v int8
}

//go:noinline
func loadHitStore8(x int8, p *t) int32 {
        p.v = x
        return int32(p.v)
}

Compiles to:

  b1:
    v1 = InitMem <mem>
    v2 = SP <uintptr>
    v3 = SB <uintptr> DEAD
    v4 = Addr <*int8> {x} v2 DEAD
    v5 = Addr <**t> {p} v2 DEAD
    v6 = Addr <*int32> {~r2} v2
    v7 = Arg <int8> {x}
    v8 = Arg <*t> {p}
    v9 = Const32 <int32> [0] DEAD
    v10 = NilCheck <void> v8 v1
    v11 = OffPtr <*int8> [0] v8 <----------- type = *int8
    v12 = Store <mem> [1] v11 v7 v1
    v13 = NilCheck <void> v8 v12
    v14 = OffPtr <*t> [0] v8 <-------------- type = *t
    v15 = Load <int8> v14 v12
    v16 = SignExt8to32 <int32> v15
    v17 = VarDef <mem> {~r2} v12
    v18 = Store <mem> [4] v6 v16 v17
    Ret v18

Since the types of v11 and v14 are different the generic rules can't tell that they are really the same pointer, and so cannot turn v15 into a Copy.
@randall77
Copy link
Contributor

Why isn't v14 being rewritten to v8?

(OffPtr [0] x) && x.Type == t -> x

v11 is still a problem.

@mundaym
Copy link
Member Author

mundaym commented Feb 17, 2017

It is later, this snapshot is before the optimization pass.

@gopherbot
Copy link

CL https://golang.org/cl/37254 mentions this issue.

@golang golang locked and limited conversation to collaborators Feb 21, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge Performance
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@josharian @randall77 @gopherbot @mundaym