New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider moving semantic actions to functions, leave inlining decisions to LLVM/rustc #8
Comments
osa1
added
perf
Related to runtime performance
code size
Related to generated code size
labels
Jun 4, 2021
We could also add a syntax (maybe reuse Rust attribute syntax) to force inlining a RHS. |
This is blocking #16. |
osa1
added a commit
that referenced
this issue
Oct 19, 2021
osa1
added a commit
that referenced
this issue
Oct 19, 2021
- To be able to implement backtracking in #16 we need to store semantic action of the last accepting state we've seen. For that we need functions for semantic actions. - DFA simplification duplicates semantic actions, having functions for semantic actions means we leave inlining decisions to the compiler (fixes #8).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
With #7 we now generate much more efficient code, but in principle it could lead to code size explosion when some semantic actions have large code and lots of incoming edges in the DFA. I didn't see this happen in practice yet, but I think it could happen.
If we introduce a top-level function for semantic actions, then duplicated code will just be a call expression to the semantic action function. Inlining the semantic action code is then left to LLVM/rustc. I think this would give us more or less the same result for small semantic actions and avoid code size blowup in the worst case.
The text was updated successfully, but these errors were encountered: