bison patch to help gcc?

[Tim Josling]

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).