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: ssa debug does not regenerate/update ssa.html #31290

Open
cuonglm opened this issue Apr 5, 2019 · 12 comments
Open

cmd/compile: ssa debug does not regenerate/update ssa.html #31290

cuonglm opened this issue Apr 5, 2019 · 12 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@cuonglm
Copy link
Member

cuonglm commented Apr 5, 2019

What version of Go are you using (go version)?

$ go version
go version devel +db0c524211 Fri Apr 5 15:42:17 2019 +0000 linux/amd64

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/cuonglm/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/cuonglm/go"
GOPROXY=""
GORACE=""
GOROOT="/home/cuonglm/sources/go"
GOTMPDIR=""
GOTOOLDIR="/home/cuonglm/sources/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build070945894=/tmp/go-build -gno-record-gcc-switches"

What did you do?

file p.go:

package p

func p(slc []byte, i uint) {
	if len(slc) >= 3 {
		_ = slc[i%3]
	}
}
$ GOSSAFUNC=p GO111MODULE=off go-tip build
# _/home/cuonglm/bin/go/29872
dumped SSA to ./ssa.html
$ cp ssa.html ssa.html.bak
$ diff ssa.html ssa.html | wc -l
0

Edit p.go to become:

package p

func p(slc []byte, i uint) {
        i = 1
	if len(slc) >= 3 {
		_ = slc[i%3]
	}
}

Then:

$ GOSSAFUNC=p GO111MODULE=off go-tip build
# _/home/cuonglm/bin/go/29872
dumped SSA to ./ssa.html
$ diff ssa.html ssa.html.bak | wc -l
6

Seems good. Change p.go to original content, mean remove line i = 1. Then:

$ GOSSAFUNC=p GO111MODULE=off go-tip build
# _/home/cuonglm/bin/go/29872
dumped SSA to ./ssa.html

# Here the content of ssa.html and ssa.html.bak must be the same
# but they don't.

$ diff ssa.html ssa.html.bak | wc -l
6
$ rm ssa.html
$ GOSSAFUNC=p GO111MODULE=off go-tip build
# _/home/cuonglm/bin/go/29872
dumped SSA to ./ssa.html
$ ls
p.go  ssa.html.bak

What did you expect to see?

ssa.html content always update, and file is re-created after deleting.

What did you see instead?

Content never updates from 3rd run, file is not re-created after deleting.

@cuonglm
Copy link
Member Author

cuonglm commented Apr 5, 2019

Using:

GOSSAFUNC=p+ GO111MODULE=off go-tip build

I see the content printed to stdout is correct, only the file ssa.html not updated/re-created.

@randall77
Copy link
Contributor

I can reproduce. I don't think it is what you think it is, though.
I get the same behavior if I just do:

$ GOSSAFUNC=p GO111MODULE=off go-tip build
$ mv ssa.html ssa.html.bak
$ GOSSAFUNC=p GO111MODULE=off go-tip build
$ diff ssa.html ssa.html.bak | wc -l

I get 6, not 0.
I suspect there's a timestamp or something that is generating this difference. Unfortunately, while the diff is only 6 lines, it's ~560KB, so it's hard to see exactly what the difference is.

I agree it would be nice to make the ssa.html output repeatable.

@josharian @ysmolsky

@cuonglm
Copy link
Member Author

cuonglm commented Apr 6, 2019

@randall77 can you try with other function name instead of p? A name that you’ve never used before.

@randall77
Copy link
Contributor

Why would that matter?
I agree that compiling the same code should generate the same ssa.html, and it currently doesn't.
My example just shows you don't need to change the code and then change it back. Just compile the same code twice. The two ssa.html's that are produced are different.

@cuonglm
Copy link
Member Author

cuonglm commented Apr 6, 2019

@randall77 yes, but if you removed ssa.html, compiler never generate it again for that function name. Using another function name works.

@randall77
Copy link
Contributor

True, go build has a cache and won't rebuild the identical source file again.
(I lied - I was using go tool compile and not go build.)

@ysmolski
Copy link
Member

ysmolski commented Apr 6, 2019

Oh yeah. I am very well aware of this issue with go build. I used to provide changing env vars to it to trigger ssa.html generation when I could not use go tool compile. I am not sure about solution here because probably it lies in changing the "build" command.

@josharian
Copy link
Contributor

I agree that compiling the same code should generate the same ssa.html, and it currently doesn't.

A quick search-and-replace of "<" with "\n" in the ssa.htmls yields a diff like:

1131c1131
< span class="stats">[10569 ns]
---
> span class="stats">[11420 ns]
1543c1543
< span class="stats">[5937 ns]
---
> span class="stats">[6914 ns]
1953c1953
< span class="stats">[1263 ns]
---
> span class="stats">[1791 ns]
2363c2363
< span class="stats">[11318 ns]
---
> span class="stats">[24605 ns]
2623c2623
< span class="stats">[4633 ns]
---
> span class="stats">[8060 ns]
2883c2883
< span class="stats">[11829 ns]
---
> span class="stats">[14419 ns]
3179c3179
< span class="stats">[502 ns]
---
> span class="stats">[639 ns]

I don't care much about the timing info, so we could remove it. Not sure how much it matters vs perfect reproducibility.

@randall77
Copy link
Contributor

Ah, that makes sense. I was worried it was something nondeterministic about the compiler.

Might be kind of nice to have timing info only if you ask for it with a flag.
I don't think it is super important either way.

@bcmills bcmills added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Apr 11, 2019
@bcmills bcmills added this to the Unplanned milestone Apr 11, 2019
@bcmills bcmills added NeedsFix The path to resolution is known, but the work has not been done. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Apr 11, 2019
@gopherbot gopherbot removed the NeedsFix The path to resolution is known, but the work has not been done. label Apr 11, 2019
@bcmills
Copy link
Contributor

bcmills commented Apr 11, 2019

From the perspective of go build, the output of GOSSAFUNC is not actually part of the build graph. It isn't tracked as an output, and its contents are not used to invalidate other things.

It is, quite literally, treated as magic:

// TODO(rsc): Convince compiler team not to add more magic environment variables,
// or perhaps restrict the environment variables passed to subprocesses.
magic := []string{
"GOCLOBBERDEADHASH",
"GOSSAFUNC",
"GO_SSA_PHI_LOC_CUTOFF",
"GOSSAHASH",
}

@agnivade
Copy link
Contributor

Latest victim of this. I was testing something with a freshly minted compiler and then compared with go1.12. And when I went back to generating with the tip, then the result was same as go1.12 !

When it happened the first time, I thought maybe I had made a mistake the first time. Was stuck quite some time with this. I got totally stumped when I deleted the file but it never generated it again ! Then I decided to rebuild the compiler with an incorrect instruction, and then saw it generate again. Only then I remembered there was an issue like this, and came to add my report.

What is the general guideline to workaround this ? Renaming functions work, but is that what everyone does ?

@dragonly
Copy link

dragonly commented Dec 9, 2022

I met this again using go version go1.19.3 darwin/arm64.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

8 participants