Explore partial inlining

[niloc132]

The current MethodInliner attempts to inline an entire static Java method if the method itself is small enough to justify inlining and it won't result in changes to the callsite that could alter its side effects.

I believe our existing type tightener passes are able to detect that the union of all types passed to a given method are the same type, such as "non-nullable string" - given that information, the compiler could then today rewrite away a null check inside the method, which could make it eligible for inlining.

However, if there are a mix of nullable and non-nullable callsites, then we end up in the situation where some could be optimized easily - partial inlining would let us examine a top-level if/else branch in a method, and only inline one side of it, if we can statically prove that the condition is either true or false for the caller.

Example:

gwt/user/super/com/google/gwt/emul/javaemul/internal/InternalPreconditions.java

Lines 402 to 407 in 4e6ae10

	public static <T> T checkCriticalNotNull(T reference) {
	if (reference == null) {
	throw new NullPointerException();
	}
	return reference;
	}

If we statically know that the parameter can never be null, we could just remove this call entirely, such in

checkCriticalNonNull("foo") == null;

That constant can never be null, so checkCriticalNonNull is inlined away as just the argument, and in turn now, the == can be optimized out too.

This is harder than this post makes it sound in general, but if we just focus on null and instanceof checks, we can probably make a dent in cases like this.