Patch to fix parse time message
Sat Apr 26 06:33:00 GMT 2003
This patch corrects the text of the -ftime-report output, so that the
"parser" time is correctly reported as "parser and actions".
ChangeLog is at the end and the patch with date to be filled in) is
While other possible more elaborate patches may be better, this one is a
step in the right direction and therefore should be approved IMHO. This
one has the advantage that it can be implemented now.
Bootstrapped on i586-pc-linux-gnu and ran cobol/treelang test suites.
Ran some compiles with -ftime-report and it printed OK.
Can I apply it?
With option -ftime-report and other similar options such as -Q, GCC
reports all the time in the parser and some time spent in 'parser
actions' as "parser". Periodically, this leads to calls to rewrite the
parser, usually the suggestion is to hand code it.
In fact some parsers have already been hand coded, for this and other
I have determined that
1. Typically about 2/3 of the parser time is not bison's fault, and
therefore bison is being unjustly criticised.
2. Adding a new time category such as 'parser actions' is problematic
and unikely to happen. My previous patch was rejected and I see little
chance of getting anything accepted in a reasonable time frame with
a) Bison lacks a feature to hook into just as you enter and exit
actions. So one must post process the bison output, or change bison to
add such a feature. Changing bison would not be simple or fast, though
Akim was responsive to the suggestion. He suggested a somewhat more
ambitious change which is out of scope for me.
Postprocessing the output was rejected when I submitted a patch to do
this some time back.
b) Time calls on entry and exit to every action add significantly to CPU
time. The extra cc1 time is about 0.4% even with the timing options
turned off. So you would need to add a configure option to disable it. I
did this in my previous patch, but that had the disadvantage that if say
Red Hat turned the option off, people would not be able to do
-ftime-report and have it work, without building the compiler themselves.
Previous tests suggested that the overhead would not be significant.
However the number of entries and exits from the parser is very high,
and when calls for these are added, the overhead becomes significant.
Another suggestion to cut the overhead was to wrap all the calls in 'if'
statements. There were two problems here. There are over 100 calls, and
it would be difficult to keep such as regime in place reliably. You
could define the calls as macros, but this seems to contravene the
coding standards, by hiding conditional logic in the macros. Also, I
found that this did not actually help. All the ifs seemed to mess up the
CPUs branch tables sufficiently that there was no speedup.
c) Some languages such as Fortran and C++ have hand coded parsers. This
makes it impossible to split CPU time for parser and actions as there is
no clean point to hook into. You could add all the calls with hand
coding but I think this would not be viable.
Here is the changelog.
+2003-??-?? Tim Josling <firstname.lastname@example.org>
+ * timevar.def: Change literal for parser to "parser and actions".
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the Gcc-patches