The goal of this MR is to implement a generic SIMD backend (packet ops) for Eigen that uses clang vector extensions instead of platform-dependent intrinsics. Ideally, this should make it possible to build Eigen and achieve reasonable speed on any platform that has a recent clang compiler, without having to write any inline assembly or intrinsics.
Caveats:
* The current implementation is a proof of concept and supports vectorization for float, double, int32_t, and int64_t using fixed-size 512-bit vectors (a somewhat arbitrary choice). I have not done much to tune this for speed yet.
* For now, there is no way to enable this other than setting -DEIGEN_VECTORIZE_GENERIC on the command line.
* This only compiles with newer versions of clang. I have tested that it compiles and all tests pass with clang 19.1.7.
https://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-vectorsCloses#2998 and #2997
See merge request libeigen/eigen!2051
Co-authored-by: Rasmus Munk Larsen <rmlarsen@google.com>
Co-authored-by: Antonio Sánchez <cantonios@google.com>
* add Homogeneous expression for vector and set of vectors (aka matrix)
=> the next step will be to overload operator*
* add homogeneous normalization (again for vector and set of vectors)
* add a Replicate expression (with uni-directional replication
facilities)
=> for all of them I'll add examples once we agree on the API
* fix gcc-4.4 warnings
* rename reverse.cpp array_reverse.cpp
Some naming questions:
- for "extend" we could also think of: "expand", "union", "add"
- same for "clamp": "crop", "intersect"
- same for "contains": "isInside", "intersect"
=> ah "intersect" is conflicting, so that eliminates this one !
This allow code factorization and generic template specialization
of functions
* added any_rotation * {Translation,Scaling,Transform} products methods
* rewrite of the actually broken ToRoationMatrix helper class to
a global ei_toRotationMatrix function.
NonAffine, Affine (default), contains NoShear, contains NoScaling
that allows significant speed improvements. If you like it, this concept could be applied to
Transform::extractRotation (or to a more advanced decomposition function) and to Hyperplane::transformed()
and maybe to some other places... e.g., I think a Transform::normalMatrix() function would not harm and
warn user that the transformation of normals is not that trivial (I saw this mistake much too often)
* handling Quaternion, AngleAxis and Rotation2D, 2 options here:
1- make all of them inheriting a common base class Rotation such that we can
have a single version of operator* for all the rotation type (they all get converted to a matrix)
2- write a version for all type (so 3 rotations types * 3 for Transform,Translation and Scaling)
* real documentation
- the coefficients are stored in a single vector
- added transformation methods
- removed Line* typedef since in 2D this is really an hyperplane
and not really a line...
- HyperPlane => Hyperplane
