Re: C++ PATCH: Fix PR 8338

[Mike Stump <mrs at apple dot com>]

I might have a different fix for this.  The fix involves allocating 2 
bits on type nodes, one meaning uses_template_params, and the other 
meaning doesn't use template params, I store these bits on types (the 
recursive case).  It is way better, and way faster than your fix.

You can preview the work in:

Attachment: template-3.diffs
Description: Binary data

These give a 10x speedup on the Abraham's template torture test case at:

http://users.rcn.com/abrahams/instantiation_speed/index.html

for N==200.  The changes speed up any template beefy code by large 
amounts.  Once you allocate the bits for this use, there isn't a need 
for the hashtable you have.  I believe this information is static in 
the tree.  Let me know if any of it is not.  A hashtable doesn't give 
the speed advantages using 2 bits gives.  Your change I suspect slows 
down the compiler, instead of speeding it up, well, except of course in 
the infinite case.

If you want, rip the 2 bit solution out of the patches, and try that 
out.  I hate to use the bits, but if you examine just how often we ask 
that question, and how expensive that tree walk is (very, very, very 
expensive), you'd realize that the cost of using those two bits is 
worth it.

If you want to test and put any of the other work in feel free, if not, 
I'll finish testing it up and submit it soon.

On Thursday, November 7, 2002, at 05:35 PM, Mark Mitchell wrote:
> This patch fixes PR 8338, a regression that caused the compiler to go
> into an infinite loop.  The fix may actually speed up the compiler a
> touch on some programs by avoiding walking the same nodes more than
> once in for_each_template_parm.
>
> A bigger speedup will be to use that function in dramatically fewer
> situations; coming once the new parser gets checked in.