| Summary: | Use of builtin vec_sel is ambiguous when compiling with Clang for PowerPC | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Eigen | Reporter: | João Paulo Labegalini de Carvalho <jaopaulolc> | ||||||||
| Component: | Core - vectorization | Assignee: | Nobody <eigen.nobody> | ||||||||
| Status: | RESOLVED FIXED | ||||||||||
| Severity: | Compilation Problem | CC: | chtz, gael.guennebaud, jacob.benoit.1, jaopaulolc, markos | ||||||||
| Priority: | Normal | ||||||||||
| Version: | 3.3 (current stable) | ||||||||||
| Hardware: | PPC - AltiVec | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Bug Depends on: | |||||||||||
| Bug Blocks: | 814 | ||||||||||
| Attachments: |
|
||||||||||
Created attachment 942 [details]
patch
I think you should just `reinterpret_cast` the mask to `Packet4ui` (or `Packet4i`?) I doubt that an additional comparison is required here (and `p4i_ONE` does not sound right here, but I don't know AltiVec). But the better solution would be to change the `mask` type, i.e., also change the return type of `pcmp_*`, and remove the castings there. This will also be necessary for a proper AVX512 implementation as well. You are right, just a reinterpret_cast is sufficient. Regarding the pcmp_* methods. I believe all the reinterpreting is necessary because the default implementations are all in the form of: template<typename Packet> Packet pcmp_* (Packet,Packet,Packet); A quick lock at the altivec.h include says that makes sense. When comparing packs of floats the return is a pack of floats. I am attaching the simplified patch. (I am not sure if this is good/enough for a commit) Created attachment 943 [details]
simple-patch
*** This bug has been marked as a duplicate of bug 1738 *** Open pull-request: https://bitbucket.org/eigen/eigen/pull-requests/679 *** Bug 1738 has been marked as a duplicate of this bug. *** -- 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/1718. |
Created attachment 941 [details] minimal source code example I am not sure if this is an Eigen or Clang bug. However this is the behavior. When I compile the file bug.cc (attached) with Clang for PowerPC with the following command: clang++ -target powerpc64le-unknown-linux-gnu -maltivec -I ../../eigen-mirror -o bug bug.cc I get the following error: Eigen/src/Core/arch/AltiVec/PacketMath.h:455:10: error: call to 'vec_sel' is ambiguous return vec_sel(b, a, mask); By inspecting <clang-sysroot>/lib/clang/9.0.0/include/altivec.h I have noticed that it does not define a vec_sel(float,float,float) builtin. The best candidates are vec_sel(float,float,unsigned int) and vec_sel(float,float,int). The same file (bug.cc) successfully compiles with GCC. The problem can be solved by applying the following patch: diff --git a/Eigen/src/Core/arch/AltiVec/PacketMath.h b/Eigen/src/Core/arch/AltiVec/PacketMath.h index 4b770d036..bae9cb172 100755 --- a/Eigen/src/Core/arch/AltiVec/PacketMath.h +++ b/Eigen/src/Core/arch/AltiVec/PacketMath.h @@ -452,7 +452,8 @@ template<> EIGEN_STRONG_INLINE Packet4f pandnot<Packet4f>(const Packet4f& a, con template<> EIGEN_STRONG_INLINE Packet4i pandnot<Packet4i>(const Packet4i& a, const Packet4i& b) { return vec_and(a, vec_nor(b, b)); } template<> EIGEN_STRONG_INLINE Packet4f pselect(const Packet4f& mask, const Packet4f& a, const Packet4f& b) { - return vec_sel(b, a, mask); + const Packet4ui _mask = reinterpret_cast<Packet4ui>(vec_cmpeq(reinterpret_cast<Packet4ui>(mask), reinterpret_cast<Packet4ui>(p4i_ONE))); + return vec_sel(b, a, _mask); }