[PATCH] D76811: [X86] Refactor X86IndirectThunks.cpp to Accomodate Mitigations other than Retpoline [2/3]

[Zola Bridges via Phabricator via llvm-commits]

zbrid added a comment.

I think I got all the answers to my questions from elsewhere. Lmk if these don't follow your rationale.

> - What do you mean by allowing the compiler to devirtualize?
> - Why is it preferable to allow the compiler to devirtualize?

devirtualize -> Avoid virtual dispatch. Virtual dispatch has overhead we prefer to avoid. LLVM has a preference to avoid virtual dispatch where possible and there is precedent within the codebase for using CRTP.

> - Why is it desirable to allow the compiler to inline RetpolineThunkInserter's methods?

Performance

> - Why is that preferable to readability in this case?

Following LLVM precedent.

> - Is the implication that there is a large perf impact to not use CRTP?

Yes.

----

More comments later once I go through the whole thing. Sorry about not code reviewing all at once. I know it's not a desirable pattern.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76811/new/

https://reviews.llvm.org/D76811