You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
builder: linking the package modules one by one is quadratic in program size #5834
The program job in builder/build.go links every package's bitcode into one module in a loop, so the linker walks the growing module once per package. On a program of 1450 packages that step took longer than compiling, interpreting and optimizing together.
Building skycoin (github.com/skycoin/skycoin, 356 packages, -opt=z -no-debug -tags "safe netgo noasm") on linux/amd64 with LLVM 23 takes 341 s on dev with #5782 merged (for LLVM 23) and 324 s when the modules are linked pairwise. On a 426 package program the link step went from 45 s to 10.5 s.
The change merges the modules in rounds that halve the list, so each module takes part in a logarithmic number of links. The rule that the runtime's body wins when a later package defines the same function is kept by weakening the later definition before any link: 0magnet@9b6b37e
The pairwise version needs one more change: leave functions with local linkage out of the duplicate check. Each package names its Asyncify panic replays tinygo.asyncify.panicreplay.0, .1 and so on. Weakening those to linkonce_odr let two later packages' replays meet in one pairwise link and merge, so an unrecovered panic on wasm or WASI ended in "indirect call type mismatch". The sequential link should not hit it, since the name it finds in the module is the first package's internal function, though I have only seen the failure with the pairwise link. Fix: 0magnet@65c3354
Activity
builder: link the package modules pairwise
0pcom commentedon Oct 11, 2026
The pairwise version needs one more change: leave functions with local linkage out of the duplicate check. Each package names its Asyncify panic replays tinygo.asyncify.panicreplay.0, .1 and so on. Weakening those to linkonce_odr let two later packages' replays meet in one pairwise link and merge, so an unrecovered panic on wasm or WASI ended in "indirect call type mismatch". The sequential link should not hit it, since the name it finds in the module is the first package's internal function, though I have only seen the failure with the pairwise link. Fix: 0magnet@65c3354