-
Notifications
You must be signed in to change notification settings - Fork 119
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
Sharing parse choice elements #1419
Comments
I was going to write something clever here, but I now realize I don't understand the idea. It would seem like this results in two copies of |
Sharing this one: struct Parse_choice_lr
{
Parse_set * set;
Disjunct *md; /* the chosen disjunct for the middle word */
int32_t id; /* the tracon (l_id for l_pc and r_id for r_pc */
};
You are right. It should be moved to
Where? They are not used here. Also note that I didn't explain the basis of this idea: |
Ah! OK, that makes sense now. The |
Yes. But the "encoding for parsing" step would then need to produce a tracon table (to get the tracon address by its number). Such a table is produced by the "encoding for pruning" step, which shares most of its code, so it is easy to produce it. However, we will need to find how much overhead, if any, this adds. |
OK. I guess we can leave this alone for now. Things are complicated enough, as it is. |
But the opposite thing, i.e. remove |
I found a way to replace BTW, by producing a tracon/disjunct mapping table (while encoding for parsing), it seems possible to also get rid of |
I Could not do it after all. |
I have an idea of how to memory-spare parse choice elements, just like parse set elements are shared through the x-table.
Currently, they cannot be shared because each has a unique value.
I thought of these data structures (typedefs omitted):
(What is now set[1] and set[2] will be in l_pc and r_pc, correspondingly.)
Of course, there is a question of how much sharing will be done (if any, I don't know even that) and what will be the CPU overhead.
Originally posted by @ampli in #1402 (reply in thread)
The text was updated successfully, but these errors were encountered: