Just checked in a change that will merge duplicate functions and probes.  For
probes, the duplicate C probes bodies will just call the original C probe.

Not quite done, young skywalker.  Try running the arith_limits.exp pass-5 test
case.  It looks like the new code is collapsing the test() and teststr()
auxiliary functions even though their type signatures differ!

In semantic_pass() (in elaborate.cxx), you'll see this code:

      rc = semantic_pass_symbols (s);
      if (rc == 0 && ! s.unoptimized) rc = semantic_pass_optimize (s);
      if (rc == 0) rc = semantic_pass_types (s);
      if (rc == 0) rc = semantic_pass_vars (s);
      if (rc == 0) rc = semantic_pass_stats (s);

The problem is that function argument types are still "unknown" (pe_unknown) at
the time of the optimization pass.

Before semantic_pass_types() is called, function signatures look like this:

    test:unknown (v:unknown, n1:unknown, n2:unknown)

Afterwards, they look like this:

    test:unknown (v:string, n1:long, n2:long)

At that point test() and teststr() will compare differently.

Moving the optimization pass to the end seems to fix the problem, but I'm doing
more testing.

Indeed, the optimizations are currently run before type resolution.  That's an
artifact of the first round of optimizations (see bugs #2427, #2460), and the
thread <http://sourceware.org/ml/systemtap/2006-q1/msg00261.html>.

A plausible short-term fix is to move the new pass5 optimization only
after type resolution.  It may make sense later to move all the others
past type resolution too, but this would involve having to fix:
- the test cases Joshua mentioned that rely on elision of type-incorrect code
- the translator code that throws exceptions a bit too early if unresolvable
  $target variables make it past type resolution stage.  (Instead, that pass
  could pass them through and instead let the translator.cxx code upchuck
  later.)
- maybe other stuff, as found by a full test suite regression run.

The pass5 optimization has been moved after type resolution.