The heuristic used to identify remaining uninlined calls by counting
fails when the inlining operation changes the order of "original" calls,
as may be the case with overlapping calls, following CL 535456.

I spent around an hour trying to fix this properly (by tracking calls
that were "just" inlined), but it's too hard because we must also track
calls that had previously been inlined. It needs more theory and
thought. For now, remove support for overlapping calls, as in all other
cases the top-to-bottom counting heuristic should still work.

For golang/go#63534

Change-Id: I59fe4aa5d20e56b0eb9dcbc01d29dd2ece082c17
Reviewed-on: https://go-review.googlesource.com/c/tools/+/535795
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Robert Findley <rfindley@google.com>

Joint with Alan Donovan (CL 535455) :)

For golang/go#63534

Change-Id: Ia4fdc617edf6699da285f56670a51efac1817834
Reviewed-on: https://go-review.googlesource.com/c/tools/+/534918
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

This showed up when I used the inliner for removing parameters: we
should be more precise about detecting the last use of a local var.

A TODO is left to make this perfect, which will be done in a subsequent
CL.

For golang/go#63534

Change-Id: Id5c753f3e7ae51e07db1d29a59e82e51c6d5952c
Reviewed-on: https://go-review.googlesource.com/c/tools/+/535335
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>