[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bison patch to help gcc?
From: |
Tim Josling |
Subject: |
bison patch to help gcc? |
Date: |
Thu, 27 Mar 2003 06:51:12 +1100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 |
This email is asking whether a change could be made to bison to allow
GCC to produce better compilation time statistics and to prevent further
damage to bison's reputation....
GCC currently has an option -ftime-report, which reports on the compile
CPU and elapsed time broken up into phases. One of the phases is
'parse'. This is normally quite a large percentage of the compile time:
up to 10%.
This frequently leads to suggestions to rewrite the parser in C, rather
than using bison, which must be very inefficient (as shown by the
report). The C++ parser was rewritten in C actually, maybe for other
reasons.
Now in fact, the parse time includes the bison time and also the 'parse
actions' which is not generated by bison. They are mostly calls to the
compiler internal routines which are called from the actions.
There are three problems here
1. Bison gets a bad name.
2. A lot of time is wasted with proposals to rewrite the parser to get
rid of 'inefficient' bison.
3. In some cases people actually hand coded the parsers.
I put up a patch which added a new category 'parser actions'. I added
the required timer calls by post-processing the bison output using sed.
The results from this show that about 2/3 of the 'parse' time is
actually 'parser actions' and so bison performance is good and is not an
issue.
However there is opposition to the patch because post processing the
bison output is perceived to be fragile and easily broken.
The alternative would be to add some macros to the bison skeleton, which
the user could define, but which would otherwise default to nothing
i.e.something roughly like this:
#ifndef YY_ENTER_ACTION
#define YY_ENTER_ACTION /* nothing */
#endif
#ifndef YY_EXIT_ACTION
#define YY_EXIT_ACTION /* nothing */
#endif
YY_ENTER_ACTION;
%%
YY_EXIT_ACTION;
yy....:
YY_EXIT_ACTION;
/* similar code for other labels */
So, just before the switch statement to select the action code, and
after exit from the action, the macro gets invoked. There is no extra
code generated if the user does not define the macros. Because there are
some cases where the code drops through a label, but the label can also
be jumped to, the user needs a flag to check if a change of timing mode
is actually needed.
We have hundreds of actions in the C compiler. Hand adding the timing
calls to each action is a lot of work and error prone. It would also
increase the code size considerably.
If this patch concept is acceptable I will create, document and test a
patch for inclusion in bison. Otherwise please let me know and I will
try and find another way.
Regards,
Tim Josling
(I did the FSF paperwork for contibuting to bison a while back).