RFC: Does call-graph-based function placement belong in Binaryen?
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 15/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- wasm
- Ambito
- compilers
Direzione di ricerca
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.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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.
- Lingua principale
- WebAssembly
- Stelle
- 8.7k
- Fork
- 897
- Merge medio
- 2g 4h
- PR unite (30g)
- 103
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di WebAssembly/binaryen
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
WebAssembly/binaryen#9135 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 Mezza giornata Idoneità per principianti 76/100
WebAssembly/binaryen#9018 · 3 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 62/100
WebAssembly/binaryen#9257 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 45/100
WebAssembly/binaryen#9249 ·
I maintainer di solito rispondono entro 1 giorno
-
Memory64Lowering: table.get/table.set keep i64 index on lowered table64, output fails validationAperta
Difficoltà 3/5 Mezza giornata Idoneità per principianti 66/100
WebAssembly/binaryen#9245 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di WebAssembly/binaryen
Issue simili
-
`lvm_compact` has no self-hosted twin, and `docs/158` §5 says every language-face component mustApertabug sev-3 vm
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
-
Bisect issue233157Apertabisect
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
dtcxzyw/llvm-bisect-service#545 · 1 commento ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
I maintainer di solito rispondono entro 1 giorno