[cfe-commits] PATCH: Avoid adding many builtin operator overload candidates

[Chandler Carruth]

When compiling a very large C++ unit test that does a great deal of logging,
the following pattern emerged: roughly 15% of the compilation time (26
seconds) was spent adding builtin operator overloads. This resulted in a
large amount of effort, usually including a check for IsStandardConversion
trying to convert the arguments to the parameter types. When I counted the
number of standard conversions, there were 2.9 million in this TU. Tracing
back, well over a million stemmed from a single phenomenon: builtin operator
overloads for the permutation of arithmetic types (36 total) even though
none of the argument types were or could convert to arithmetic types.

The single worst offender, by a huge margin, is basic_ios<> derived stream
objects (all standard streams) and the operator<< overload.

John McCall suggested pruning builtin operator overloads when there is no
non-record type being considered. This helps, but not tremendously. On my
test case it took my rough approximation of the number from 2.9 million to
2.7 million. The reason is that basic_ios<> in C++98 and '03 has a
conversion operator to void*. Thus I went further and also tracked whether
any of the candidate types involved in all of the arguments were either
arithmetic or enumeral types. If none are, we skip adding the arithmetic
operator overloads altogether. This dropped the number of conversions we
attempt from 2.7 million to around 1.5 million. Total parse time for the
test case file drops by over 10% (new time of 23 seconds).

The code is pretty gross. I'd like to do some further cleanups, specifically
factoring the logic for each operation type out into a function so that the
switch will just select the function to call, and the gotos and fall-through
currently employed can be represented as calls. Also, the class maintaining
state for the candidate types could use some cleaning. Let me know if I
should clean before or after adding the new functionality. Clearly, the
patch is relative to the current code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20101128/2042c2c9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ovl_reduction.patch
Type: application/octet-stream
Size: 17243 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20101128/2042c2c9/attachment.obj>