RFC: Does call-graph-based function placement belong in Binaryen?
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 15/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- wasm
- Área
- compilers
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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.
- Lenguaje dominante
- WebAssembly
- Estrellas
- 8.7k
- Forks
- 897
- Merge medio
- 2 d 4 h
- PR fusionados (30 d)
- 103
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de WebAssembly/binaryen
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
WebAssembly/binaryen#9135 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 Medio día Aptitud para principiantes 76/100
WebAssembly/binaryen#9018 · 3 comentarios ·
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 62/100
WebAssembly/binaryen#9257 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 45/100
WebAssembly/binaryen#9249 ·
Los mantenedores suelen responder en 1 día
-
Memory64Lowering: table.get/table.set keep i64 index on lowered table64, output fails validationAbierto
Dificultad 3/5 Medio día Aptitud para principiantes 66/100
WebAssembly/binaryen#9245 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
Todos los issues de WebAssembly/binaryen
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
snowballstem/snowball#311 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
JakeChampion/lang#12684 ·
Los mantenedores suelen responder en 1 día
-
`lvm_compact` has no self-hosted twin, and `docs/158` §5 says every language-face component mustAbiertobug sev-3 vm
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
-
Bisect issue233157Abiertobisect
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
dtcxzyw/llvm-bisect-service#545 · 1 comentario ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día