tinygo 0.27 hangs compiling for wasi target

[tedmielczarek-fastly]

My colleague ran into this issue while compiling a Fastly Compute@Edge module we use internally. I was able to reproduce it locally. We are both using M1 Macbooks, but he also tested compiling tinygo 0.27 from source for arm64, and that build also exhibited the same issue.

A build of this project with tinygo 0.26 takes ~1 minute on my machine. With 0.27 it seems to hang indefinitely. I have a tinygo process on my machine that has been running for 30+ minutes now, and he reported seeing it run for an hour on his machine. I sampled the process via Activity Monitor and it looks like there's a thread that's stuck running an LLVM optimization pass: https://gist.github.com/tedmielczarek-fastly/a4c0aeba01a44b88e6991953f94d97a0

I note that the 0.27 release includes #3189, which updated from LLVM 14 to 15, so this could be a regression from that.

I tried compiling a simple "hello world" Compute@Edge module and both versions of tinygo compiled it successfully in roughly the same amount of time. The module that exhibits the hang is rather large (when built with tinygo 0.26 the resulting output is a 5.7MB wasm file), so I could believe that some part of it trips a pathological case in LLVM?

I realize that this is a difficult sort of bug to track down, so I'm open to suggestions on anything I can provide that would be useful.

[aykevl]

I suspect this is because of the interp pass, which tries to run package initializers at compile time.

[codefromthecrypt]

I have source generated with github.com/planetscale/vtprotobuf and it hangs, also (even dev branch). Wonder if related.

[codefromthecrypt]

FYI: something about how https://github.com/knqyf263/go-plugin uses vtprotobuf avoids the compilation hang. Using this plugin even if you aren't developing services, is a workaround for proto.