Closed howjmay closed 3 years ago
Close via commit 300dc7ee45e9d6c76080d6c029d28dd8a802dff1
This has a collision on Apple silicon and boost's date_time library, as they also have a function called likely. See https://www.boost.org/doc/libs/1_77_0/boost/date_time/special_values_parser.hpp
Could we prefix sse2neon's likely and unlikely with something so that these types of collisions are less "likely" to occur?
This has a collision on Apple silicon and boost's date_time library, as they also have a function called likely. See https://www.boost.org/doc/libs/1_77_0/boost/date_time/special_values_parser.hpp
Could we prefix sse2neon's likely and unlikely with something so that these types of collisions are less "likely" to occur?
@jmather-sesi, Thanks for pointing this out. It should be fixed in commit 767e5bfadf6ff4d346ddd483d178640274c25a10.
As mentioned in https://github.com/DLTcollab/sse2neon/pull/130#discussion_r502794219 We can introduce macro
likely
andunlikely
for adding instruction that make branch prediction prefer for the if condition withlikely
macro.reference
https://stackoverflow.com/questions/109710/how-do-the-likely-unlikely-macros-in-the-linux-kernel-work-and-what-is-their-ben