[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.

In D76811#1952580 <https://reviews.llvm.org/D76811#1952580>, @sconstab wrote:

> By the way, I had initially implemented this patch with a pure virtual base class and a retpoline thunk (and later LVI thunk) class that implements the interface. However, I could not for the life of me structure the classes in a manner that would allow the compiler to devirtualize. Using CRTP admittedly sacrifices some readability, but it does not prevent the compiler from inlining `RetpolineThunkInserter`'s methods.


Asking to learn here. I've not heard of CRTP and don't quite understand your explanation.

- What do you mean by allowing the compiler to devirtualize?
- Why is it preferable to allow the compiler to devirtualize?
- Why is it desirable to allow the compiler to inline RetpolineThunkInserter's methods?
- Why is that preferable to readability in this case? Is the implication that there is a large perf impact to not use CRTP?

More comments later.



================
Comment at: llvm/lib/Target/X86/X86IndirectThunks.cpp:77
+  void insertThunks(MachineModuleInfo &MMI);
+  void populateThunk(MachineFunction &MF);
+};
----------------
Why not define this and the above function inline like you do for the LVI version in the 3/3 patch in this series?


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

https://reviews.llvm.org/D76811