swift

0de00d1c - [sil-inst-opt] Improve performance of InstModCallbacks by eliminating indirect call along default callback path.

[sil-inst-opt] Improve performance of InstModCallbacks by eliminating indirect call along default callback path. Specifically before this PR, if a caller did not customize a specific callback of InstModCallbacks, we would store a static default std::function into InstModCallbacks. This means that we always would have an indirect jump. That is unfortunate since this code is often called in loops. In this PR, I eliminate this problem by: 1. I made all of the actual callback std::function in InstModCallback private and gave them a "Func" postfix (e.x.: deleteInst -> deleteInstFunc). 2. I created public methods with the old callback names to actually call the callbacks. This ensured that as long as we are not escaping callbacks from InstModCallback, this PR would not result in the need for any source changes since we are changing a call of a std::function field to a call to a method. 3. I changed all of the places that were escaping inst mod's callbacks to take an InstModCallback. We shouldn't be doing that anyway. 4. I changed the default value of each callback in InstModCallbacks to be a nullptr and changed the public helper methods to check if a callback is null. If the callback is not null, it is called, otherwise the getter falls back to an inline default implementation of the operation. All together this means that the cost of a plain InstModCallback is reduced and one pays an indirect function cost price as one customizes it further which is better scalability. P.S. as a little extra thing, I added a madeChange field onto the InstModCallback. Now that we have the helpers calling the callbacks, I can easily insert instrumentation like this, allowing for users to pass in InstModCallback and see if anything was RAUWed without needing to specify a callback.