Skip to content
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

Closed
osa1 opened this issue Jun 4, 2021 · 2 comments · Fixed by #19
Closed
Labels
code size Related to generated code size perf Related to runtime performance

Comments

@osa1
Copy link
Owner

osa1 commented Jun 4, 2021

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.

@osa1 osa1 added perf Related to runtime performance code size Related to generated code size labels Jun 4, 2021
@osa1
Copy link
Owner Author

osa1 commented Oct 12, 2021

We could also add a syntax (maybe reuse Rust attribute syntax) to force inlining a RHS.

@osa1
Copy link
Owner Author

osa1 commented Oct 18, 2021

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
osa1 added a commit that referenced this issue Oct 19, 2021
osa1 added a commit that referenced this issue Oct 19, 2021
@osa1 osa1 closed this as completed in #19 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
Labels
code size Related to generated code size perf Related to runtime performance
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant