Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

StringLifting?

Abierto
  • ¿Algo no está bien?
#7,370 4 comentarios 0 reacciones 0 asignados Ver en GitHub

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
cpp, wasm
Área
compilers

Línea de trabajo

Comienza con el pass StringLowering existente y contexts.h; después, reproduce el timing de --string-lowering-magic-imports del issue en un archivo WebAssembly representativo. Rastrea cómo fluyen los valores externref importados a través de locales, globales, parámetros, resultados, campos y tags; se considera terminado cuando exista un diseño concreto y robusto de lifting o una decisión documentada de no continuar con ello.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

It would be nice to allow toolchains to emit magic JS string imports all the time, which would make the output immediately runnable in VMs. That would be instead of emitting stringref and letting Binaryen lower it. The benefit of stringref is that Binaryen can optimize strings (it has them in the IR), but in a debug build you don't need that, and just want to run the build. Right now, toolchains can do some work to emit either JS string imports or stringref, depending on build type (debug or optimized), but we could save them the effort if Binaryen could read JS string imports and turn them into optimizable stringref.

We already have a StringLowering pass that turns stringref into JS string imports, which works well, so we could have a StringLifting that does the inverse. However, the inverse problem is a lot harder, consider e.g.

(module
  (import "\'" "foo" (global $string.foo externref))
  (func $use
    (local $temp externref)
    (local.set $temp (global.get $string.foo))
  )
)

We can turn that imported JS string into a string.const, but the type would change from externref to stringref, and no longer fit in the local.

The existing lowering pass handles this by just turning every stringref into externref, which is fine as the goal is to lower away all native wasm strings. But we can't do that in a lifting pass, as there might be legitimate and unrelated externref uses to keep.

Inferring the types to change (in locals, globals, params, results, struct and array fields, tags, etc. etc.) would be... challenging, and likely brittle.

If we used type imports this could work - toolchains would not use raw externref but something more specific. But that proposal is far off (phase 1), so toolchains can't depend on it.

We could use custom annotations instead. I looked a little into how that might work, but it seems like in contexts.h, where we get the annotations, we'd need to do something with them. That seems like a widespread and annoying change at the parsing level. Perhaps instead we could stash the annotations on the IR or on the side (like we do with debug info), and then a lifting pass could use that?

To be honest that doesn't seem very appealing either, both in terms of needed work on the Binaryen side, and toolchains - they'd need to add these annotations everywhere, and forgetting some annotation - say on some struct field - would lead to very odd errors.

As all of this is meant to save toolchains time, I looked at a huge 33MB wasm file from Java (the largest file I have that uses strings). Running --string-lowering-magic-imports (and reading and writing the binary) takes 14 seconds on my modest laptop - on a beefy machine it would be significantly faster. So we are talking single digits of seconds here, most likely. In that case, the benefit to toolchains seems pretty modest?

@tlively What are your thoughts here?

Lenguaje dominante
WebAssembly
Estrellas
8.6k
Forks
892
Merge medio
1 d 18 h
PR fusionados (30 d)
79

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de WebAssembly/binaryen

Todos los issues de WebAssembly/binaryen

Issues similares

Más issues de Compilers

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.