feat(compiler): Improve constant pattern matching #2173
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This improves the code generation for our pattern matching engine, the goal is to make it so binaryen can build
br_tables
in more cases.This changes how we generate code for our wasm output generation so in certain cases when we are matching on a static constant such as a short type, or constructor as long as your data is continous i.e
'a', 'b', 'c'
and we are not outputting a default (not grain's wildcard default but a default in the constant path of our decision tree) then we will use a jump table, in cases where the data is not continous and you have a default we perform the untagging first and do direct i32 equality checks which reduces code size a little and allows binaryen to optimize into a jump table in more cases). This lowers codegen our output size by a couple bytes in a few cases but more importantly on large constant matches it allows us todo a direct jump instead of a bunch of equality checks and it allows us to save on memory operations by getting the values ofint32
,int64
theuint
equivlants andadt variants
before our comparisions.We could furthur improve codegen in a few ways, we could handle the default case this would require changing up
compile_switch
to accept aDefault(anf_expression)
instead of justPartial
orTotal
which would allow us to optimize more cases into jump tables, additionally we could handle non continous datasets (i.e ones with gaps), by changing how we generate our jump_table slightly (I did not have a good heurtistic for this though and could not find good data on how many dead branches make sense vs not, as we just point the dead_branches in the gaps to the default branch).closes: #1185