RFC: Does call-graph-based function placement belong in Binaryen?
Mantenedores costumam responder em até 1 dia
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 5/5
- Tempo estimado
- Mais de uma semana
- Facilidade para iniciantes
- 15/100
- Tipo de issue
- Funcionalidade
- Clareza
- Razoavelmente clara
- Status de atividade
- Ativa
- Stack de tecnologia
- wasm
- Domínio
- compilers
Direção de pesquisa
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.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
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.
- Linguagem predominante
- WebAssembly
- Estrelas
- 8.7k
- Forks
- 897
- Merge médio
- 2d 2h
- PRs com merge (30d)
- 101
Preparar o ambiente
- Sem Dockerfile nem arquivo Docker Compose
- Sem modelo de pull request
- Ler o guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de WebAssembly/binaryen
-
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 88/100
WebAssembly/binaryen#9135 · 1 comentário ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 Meio dia Facilidade para iniciantes 76/100
WebAssembly/binaryen#9018 · 3 comentários ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 76/100
WebAssembly/binaryen#9291 · 1 comentário ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 62/100
WebAssembly/binaryen#9257 · 2 comentários ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 45/100
WebAssembly/binaryen#9249 ·
Mantenedores costumam responder em até 1 dia
Todas as issues de WebAssembly/binaryen
Issues semelhantes
-
bug P2
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 74/100
Mantenedores costumam responder em até 1 dia
-
REPL and --show-tokens abort with "Token conversion not implemented yet" on .xor., byte and in outAbertabug low priority tokenizer
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
Mantenedores costumam responder em até 1 dia
-
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 76/100
WebAssembly/spec#2300 ·
Mantenedores costumam responder em até 1 dia
-
crash generated by fuzzer mlir
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
llvm/llvm-project#234636 · 1 comentário ·
Mantenedores costumam responder em até 1 dia
-
bug PyCDE
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 74/100
Mantenedores costumam responder em até 1 dia