4 ms·

I was going to write a response but bdash over on reddit did a great job, so I'll just link that: https://www.reddit.com/r/programming/comments/3wla9f/chris_lat

I was going to write a response but bdash over on reddit did a great job, so I'll just link that: https://www.reddit.com/r/programming/comments/3wla9f/chris_lattner_author_of_the_swift_programming/cxx7k0m https://www.reddit.com/r/programming/comments/3wla9f/chris_l... One interesting note is that, the last time I looked into this, the compiler _is_ allowed to assume that multiple sequential vtable calls do not replace the vtable, allowing the vtable lookup to be cached. But that is not true for some arbitrary external-to-the-compilation-unit function that.

bdash 11y ago
In practice neither GCC nor Clang seem to be willing to believe that the vtable is immutable. See https://goo.gl/y0cx1r https://goo.gl/y0cx1r, for example, which shows only the first of two calls being devirtualized. The call to fprintf within B::work is sufficient to cause to both compilers to reload the vtable pointer, preventing devirtualization of the second call. Interestingly enough, when a use of placement new is visible to the compiler it can prevent the conservative behavior mentioned above. In https://goo.gl/Y8rwYG https://goo.gl/Y8rwYG the vtable store that placement new conceptually generates allows Clang to devirtualize the second virtual call. GCC doesn't appear to catch this case.
- chadaustin 11y ago
  Thanks for digging in! I saw the same thing with clang last year, in the context of Emscripten, where we were hoping to eliminate the redundant vtable loads as a JS code size optimization.