Don't. That is, don't make any assumptions about what goes on under the hood there. Maximally optimized code won't necessarily be so next year anyway. And maximally optimized code would be CPU & system dependent. It would be problem dependent, because problems of different sizes might involve differing tricks to be truly optimal.
Even something as simple as a matrix*matrix multiply has been shown to be non-obvious. For example, carefully time how long a matrix*matrix multiply takes, then plot the time required as a function of the order of the matrix. For nxn matrices, this should be an O(n^3) problem, scaling smoothly, because your CPU will just pump those adds and multiplies through as fast as it can. And we can count just how many such ops are needed. But various factors conspire here, from the blas to cache size, etc. So what happens is that curve of time versus order is not a smooth one, even after you reduce the noise by replication. The bumps will be system dependent, and consistent, but they will also potentially change with release, nor should you bother to try to find some subtle tweak to avoid them.
Spending a lot of time to chase subtle features in JIT is a waste of time. Instead, spend that time to profile your code if there are bottlenecks. Then spend time to either alleviate those specific identified bottlenecks, or just move on and accept tham.
