Capturing the idea from an email thread. Can we craft an interprocedural analyzer that identifies call sites that call an overly conservative library function, when a faster one is available? Or conversly, identify library functions with a redundant guard, where the guard is determined to be redundant based on analyzing all call sites. Such analyses can be taylored to specific library functions. Lars wrote: Observe: /*static*/ Stringp String::concatStrings(Stringp leftStr, Stringp rightStr) { if (leftStr == NULL || leftStr->m_length == 0) return rightStr; return leftStr->_append(rightStr, Pointers(rightStr), rightStr->length(), rightStr->getWidth()); } Stringp String::append(Stringp rightStr) { if (rightStr == NULL || rightStr->m_length == 0) return this; return _append(rightStr, Pointers(rightStr), rightStr->length(), rightStr->getWidth()); } // NB: if rightStrPtr is nonnull, it is assumed to be the source of rightStr. // In this case, rightStr is assumed to be invalidate by any possible GC activity, // and will be re-created from rightStrPtr. Stringp String::_append(Stringp rightStrPtr, const Pointers& rightStr, int32_t numChars, Width charWidth) { if (numChars <= 0) return this; ... } (a) I suspect the call in concatStrings should not be to _append but to append since rightStr could be NULL (b) I wonder if the NULL checks are actually necessary at all in concatStrings and append, and if so, from which call sites (c) Those may be tail calls with GCC, but with MSVC? That is, there are correctness, overkill, and efficiency issues here. An interprocedural optimizer might fix some of them but with the code size paranoia^Wconcerns on the FP team such an optimizer may never be turned on if it results in a lot of specializations being generated. It may be that an analysis pass might be brought to bear to discover necessary invariants and redundant tests.

Tamarin is a dead project now. Mass WONTFIX.

Tamarin isn't maintained anymore. WONTFIX remaining bugs.