You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have been trying out the --enable-gc-nn-locals flag on some output modules from dart2wasm. I was surprised to find that the optimized Binaryen output when using non-nullable locals was bigger than the one using only nullable locals, even though for the original modules, the one using non-nullable locals was smaller.
I looked at the output and noticed a few things:
The optimized non-nullable version doesn't actually contain any non-nullable locals. This is the case even for a non-optimizing wasm-to-wat pass-through.
The code contains many superfluous ref.as_non_null, i.e. on a non-nullable value or as input to something accepting a nullable value.
It looks like the code was processed with non-nullable locals in mind, but for the output, the locals somehow became nullable and all the ref.as_non_null were inserted to make the types match up.
Since at least some of these could potentially trap, it would seem that removing them is only valid with the --ignore-implicit-traps option. Thus, a fix for #3934 could be valuable for doing a fair comparison between having non-nullable locals and not.
The text was updated successfully, but these errors were encountered:
We only tested that feature on the text format. For binary support, the reader needs
to know that the feature is enabled, so that it allows non-nullable locals in that
case (i.e., does not apply the workarounds to remove them).
Fixes#3953
I have been trying out the
--enable-gc-nn-locals
flag on some output modules fromdart2wasm
. I was surprised to find that the optimized Binaryen output when using non-nullable locals was bigger than the one using only nullable locals, even though for the original modules, the one using non-nullable locals was smaller.I looked at the output and noticed a few things:
ref.as_non_null
, i.e. on a non-nullable value or as input to something accepting a nullable value.It looks like the code was processed with non-nullable locals in mind, but for the output, the locals somehow became nullable and all the
ref.as_non_null
were inserted to make the types match up.Since at least some of these could potentially trap, it would seem that removing them is only valid with the
--ignore-implicit-traps
option. Thus, a fix for #3934 could be valuable for doing a fair comparison between having non-nullable locals and not.The text was updated successfully, but these errors were encountered: