Replacing `memset` and `memcpy` calls with `memory.fill` and `memory.copy`?
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
- 25/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- wasm
- Área
- compilers
Línea de trabajo
Comienza revisando la arquitectura de pases de wasm-opt y cómo la funcionalidad bulk-memory habilita memory.fill y memory.copy. Determina si el pase debe reconocer llamadas con nombre a memset/memcpy o bucles de control de flujo; después, confirma el alcance aceptado y define pruebas que muestren las sustituciones previstas.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
If I were to try working on a wasm-opt pass doing what's written in the title, would it be accepted? Gated behind the bulk-memory extension/feature of course.
The rationale I have for this is that when compiling Rust, even with the bulk-memory target feature (codegen option) enabled, a lot of naive (slow) memcpy and memset calls are left in the result, because they are called from std/core library functions, such as __rust_alloc_zeroed and __rust_realloc. These can be avoided by passing the build-std option to Cargo, but that is still an unstable, nightly-only feature.
Of course, this sets some assumptions about what a function that happens to be named "memset" or "memcpy" is supposed to be doing, but in a lot of compiler toolchains, these are pretty much already handled as intrinsics anyway.
One alternative would be to detect some forms of memory copying or filling loops in the control flow graph instead, and only replace those with intrinsics.
What do you think?
- Lenguaje dominante
- WebAssembly
- Estrellas
- 8.7k
- Forks
- 893
- Merge medio
- 1 d 18 h
- PR fusionados (30 d)
- 79
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 2/5 1-3 horas Aptitud para principiantes 76/100
WebAssembly/binaryen#9185 ·
Los mantenedores suelen responder en 1 día
-
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 4/5 3-5 días Aptitud para principiantes 52/100
WebAssembly/binaryen#9186 ·
Los mantenedores suelen responder en 1 día
-
LoopInvariantCodeMotion: `struct.new` is hoisted out of a loop, so all iterations share one objectAbierto
Dificultad 3/5 1-2 días Aptitud para principiantes 68/100
WebAssembly/binaryen#9184 ·
Los mantenedores suelen responder en 1 día
Todos los issues de WebAssembly/binaryen
Issues similares
-
E editing with a field wider than ~511 characters crashes (stack smashing in handle_decimal)Abiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
Los mantenedores suelen responder en 1 día
-
todo:ticket
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 Menos de una hora Aptitud para principiantes 90/100
Los mantenedores suelen responder en 1 día
-
bug engine spec compliance
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
frostney/GocciaScript#1402 ·
Los mantenedores suelen responder en 1 día
-
bug needs triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
Los mantenedores suelen responder en 1 día