Breaking up the 'parse' time into 'parse/bison' and 'parse/other'

[Tim Josling]

Recapping: Option -Q gives you a breakup of the time spent in the various
compiler phases. It misleadingly, according to me, gives a high number for the
parser because it also counts all the code in the parse 'actions'. So people
are always suggesting we rewrite the parsers in native code.

The plan is I will produce a patch that breaks parse time into "parse/bison"
and "parse/actions", or some such wording.

Here are the results of my research: 

Not all front ends actually support -Q, it would seem. Some have alternative
schemes, like c++ -fstats.

There are quite a few hand coded lexers (everything except treelang), even
quite a few hand coded parsers (everything except treelang/C/OBJC). In these
front ends it can be quite unclear what is parse and what is actions. So for
the moment I will leave the hand coded parser languages in the too hard
basket.

With the bison based parsers, there seem to be three alternatives.

1. Post process the bison output .c file and add in calls to
timevar_push/timevar_pop to record going in and out of the parser actions. The
push would be just before the big switch (yyn). The pops would be at the
labels that the macros like YYERROR return to and at the point right after the
switch body. This may be somewhat fragile.

2. Put push and pop calls into all the actions, of which there are hundreds to
thousands depending on the language. I don't like adding this much code and
trying to get everyone to keep it correct.

3. Get bison to add hooks which we could use. This could be a long term plan
to follow on from (1). According to the doc, GCC must be built with bison, not
byacc or yacc.

My theory at the moment is 

a) Post process the bison output file and add the push/pop calls.
b) Ask bison to add some hooks we can use long term

I considered adding a configuration option to turn off the data gathering and
reporting. I tested this and it made zero difference to the compilation speed.
I thought it would but it didn't. 

Anyway, before I submit any patch I will report some preliminary results to
verify if the split is worthwhile. Any comments welcome...

Tim Josling