The expression parser is currently too slow due to its recursive nature. It
could be speed up by rewriting it so that it manually tracks precedences.
Bug 14179 is an example of a machine-generated testcase which exposes our
limits. I proposed a hack to help the testcase in that bug:
but the patch was rejected. Mark said:
I would like to hold off on this patch. Like Nathan says, this is the first
good evidence I've seen that implementing operator-precedence parsing might be
a measureable win on real code. If you, or Nathan, or I, or Zack, or somebody
gets to implementing that, then that's probably the best way to go. If not,
then we should consider your patch, as it really does make a big difference.
Would you mind reminding me about this patch when we get ready to make the
release branch, assuming we've not yet implemented the operator-precedence
This bug was opened to track this.
[moving discussion from PR 14179 here, since this is the PR about the new
Paolo, I did not read your email yet because I am not home. Your patch looks ok
to me and Mark already approved it; the only quirk are those gotos that totally
mess up the flow of the code. I wouldn't mind getting rid of them.
If you can do compile-time measures of your patch it would be ok, otherwise I
will in the next few days.
I have a patch which is in the PR14179. While the concept was approved, it has
At a first glance, it seems that the stage1 compiler does not have them.
Unfortunately I was low on disk space so for various reasons it is pretty well
possible that I horked something in my build directory. Since the Java
testsuite was fine, I am restarting a C++-only bootstrap that should not have
any diskspace problems.
I hope to have this finished in a few hours and to have operator-precedence
> the only quirk are those gotos that totally
> mess up the flow of the code. I wouldn't mind
> getting rid of them.
Note that the final patch has fewer gotos than the one I had sent you -- only
those strictly necessary to simulate recursion, which is in turn a pretty well
formalized transformation. I could have some very small duplication of code to
remove the gotos, but I am not really sure the flow of the code would be much
easier to understand, or rather on the contrary.
Can anybody please assign this to me?
Done. Notice that you have edit priviliges in Bugzilla if you use your
Subject: Bug 17596
Module name: gcc
Changes by: firstname.lastname@example.org 2004-09-23 11:58:20
gcc/cp : parser.c ChangeLog
2004-09-23 Paolo Bonzini <email@example.com>
* parser.c (cp_parser_token_tree_map_node,
(enum cp_parser_prec, struct cp_parser_token_tree_map_node,
binops, binops_by_token): New.
(cp_parser_assignment_expression): Use cp_parser_binary_expression.
(cp_parser_new): Initialize binops_by_token.
Many many thanks Paolo!
Let's keep this open until we get more numbers about the comparison of this
with my quick hack to speed cp_parser_initializer which is on the 3.4 branch:
Subject: Re: [3.4/4.0 Regression] expression parser is too
slow, should be rewritten
> Let's keep this open until we get more numbers about the comparison of this
> with my quick hack to speed cp_parser_initializer which is on the 3.4 branch:
Yes, I think that a simplified version of the hack may still help.
Great news. We now outperform 3.3.4 by 25% for a reduced PR14179 testcase (with
an array of 240000 elements).
I'm closing this bug and PR14179.