Revision 5e8279050bfeac11ff7b6596e927d76e321dcc3c authored by Keno Fischer on 04 August 2020, 00:46:38 UTC, committed by GitHub on 04 August 2020, 00:46:38 UTC
When inlining declines to inline something, it instead turns them into :invoke statements. These are then turned into direct (non-inlined) calls by codegen or otherwise receive a fast path at runtime. While inlining has evolved quite a bit, this code has stayed much the same since it was introduced four years ago and doesn't seem to make much sense as is. In particular: 1. For the non-`invoke()` case we were doing an extra method look that seems entirely superfluous, because we already had to do the very same method lookup just to reach this point. The only thing this path was doing at that point was creating a "compilable" specialization (which might use a slightly different signature). We might as well do that directly. 2. For the invoke case, we were pro-actively adding the specialization to the `->invokes` dispatch cache. However, this doesn't make much sense a priori either, because the bail path does not go through the runtime `invoke()` code that uses that cache (it did many years ago when this code was introduced, but hasn't in a long time). There does not seem to be a good reason to believe that this signature will be any more likely than any other to be invoked using the runtime mechanism. This cleans up that path by getting rid of both the superfluous method lookup and the superfluous addition to the `->invokes` cache. There should be a slight performance improvement as well from avoiding this superfluous work, but the bail path is less common than one might expect (the vast majority of call sites are inlined) and in measurements the effect seems to be in the noise. Nevertheless, it seems like a nice simplification and is conceptually clearer.
1 parent ea07765
VERSION
1.6.0-DEV
Computing file changes ...