RFC: Does call-graph-based function placement belong in Binaryen?
Maintainer antworten meist innerhalb von 1 Tag
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Anfängerfreundlichkeit
- 15/100
- Issue-Typ
- Feature
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Aktiv
- Tech-Stack
- wasm
- Bereich
- compilers
Rechercherichtung
This is a scope question, not a code task: the issue asks whether an opt-in call-graph-based function placement pass belongs in Binaryen at all. Read the existing reorder-functions pass to see how it differs, and check the one comment for maintainer input. Done means a maintainer answers the scope question; any algorithm or patch comes only after that.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Would an opt-in pass that places callers and callees near each other be within
Binaryen's scope? Unlike reorder-functions, which reduces index encoding
size, this would aim to improve locality in downstream execution.
The tension is:
- Lightweight runtimes may lack graph-based code placement. If they compile
and allocate code in Wasm function order, Binaryen could do the analysis
offline and potentially improve locality without adding runtime complexity. - Cache layout is outside Wasm IR's abstraction. Binaryen does not know the
final machine-code layout, and Wasm function order does not guarantee native
code proximity. This optimization would depend on runtime behavior.
Should Binaryen bridge that gap with an explicitly opt-in pass, or should this
remain a runtime-specific optimization even when lightweight runtimes cannot
practically implement it?
I'd like to settle that scope question before proposing an algorithm or PR.
- Vorherrschende Sprache
- WebAssembly
- Sterne
- 8.7k
- Forks
- 895
- Ø Merge
- 2 T. 4 Std.
- Gemergte PRs (30 T.)
- 103
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Keine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus WebAssembly/binaryen
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 88/100
WebAssembly/binaryen#9135 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 Ein halber Tag Anfängerfreundlichkeit 76/100
WebAssembly/binaryen#9018 · 3 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 62/100
WebAssembly/binaryen#9257 · 2 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 45/100
WebAssembly/binaryen#9249 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Memory64Lowering: table.get/table.set keep i64 index on lowered table64, output fails validationOffen
Schwierigkeit 3/5 Ein halber Tag Anfängerfreundlichkeit 66/100
WebAssembly/binaryen#9245 · 2 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
Alle Issues in WebAssembly/binaryen
Ähnliche Issues
-
bug frontend rt sev-3
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
Maintainer antworten meist innerhalb von 1 Tag
-
area:adapters duckdb engine:v2 status:triage triage type:bug v2
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 80/100
Maintainer antworten meist innerhalb von 1 Tag
-
Bisect issue232859Offenbisect
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 65/100
dtcxzyw/llvm-bisect-service#529 · 1 Kommentar ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
Maintainer antworten meist innerhalb von 1 Tag