Patch SparseLU
Reference issue
#2582 (closed) Does not directly address root cause, but the generic dense GEMM kernel yields the expected result. The two kernels produce results that are very similar, and pass the isApprox test. However, after hundreds/thousands of iterations, these differences could be enough to influence the detection of a pivot in a badly conditioned matrix. As for the difference between Eigen 3.3 and 3.4? I chalk that up to changes in global behavior (blocking sizes in the triangular solvers, etc) that produce small numerical differences that can eventually influence a very sensitive parameter.
What does this implement/fix?
Currently, Sparse LU has a custom dense GEMM kernel that appears fundamentally correct, but references a lot of dated code. For example: Alignment = PacketSize>1 ? Aligned : 0. Here, Aligned is deprecated and doesn't utilize alignments greater than 16. Also, this precludes Eigen from switching to a user's preferred BLAS backend (such as MKL) for dense GEMM kernels, among other Eigen features (CPU tuned blocking sizes) that have been added in the years since Gael contributed this code.
In SparseLUTransposeView there is a subtle bug that causes the SparseLU tests to fail. APIBase() calls the default constructor, which in turn sets m_isInitialized = false, even if view is initialized.