In a typical use of multiple inheritance in Eigen: class CwiseBinaryOp : internal::no_assignment_operator, public CwiseBinaryOpImpl<...> sometimes the dummy class (no_assignment_operator) comes first, which leads to suboptimal code generation by Intel Compiler. Every time it needs type casting (which is always) it injects code for null-pointer adjustment, ( if (this==1) this = 0; ) even for stack variables. Simply by reordering the inheritance order such that the dummy class is the last, this problem goes away (and there's a small but noticeable reduction in generated code size).
Does anyone see problems with changing that order? (I don't) Patch welcome!
Sounds good and easy.
https://bitbucket.org/eigen/eigen/commits/460f8913a79c/ A respective unit test would be nice, but I don't how to check that.
We could check things like CwiseBinaryOp<...> A(...); CwiseBinaryImpl<...> Abase = A; VERIFY((void*)(& A) == (void*)(& Abase))); However, on gcc this always succeeded, independently of the inheritance order (even after I added a dummy variable into no_assignment_operator), so either this test does not work, or GCC just optimizes empty classes away more aggressively than ICC.
-- GitLab Migration Automatic Message -- This bug has been migrated to gitlab.com's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.com/libeigen/eigen/issues/697.