If we have a caller that knows a particular argument can never be null, we can exploit this fact while simplifying values in the inline cost analysis. This has the effect of reducing the cost for inlining when a null check is present in the callee, but the value is known non null in the caller. In particular, any dependent control flow can be discounted from the cost estimate.
Note that this is only adjusting the inline cost analysis. As separate changes, I'm going to add support for propagating the null attribute to the call site. An alternate approach would be the have the inline cost analysis ask a ValueTracking question about the caller's formal argument. Separating this into two pieces using the already existing nonnull attribute seemed preferable.
Does anyone think I need to teach InlineFunction to exploit the attribute in the same way? Or are we willing to assume this will happen correctly after inlining?
What do you think about making this a generic wrapper around CS.paramHasAttr rather than a not-null specific wrapper? We should be careful to *always* use this method to query for attributes, and I'm not sure we do today.