Avoid duplicating a character when compiling multiple sets of instructions

Question

I use processor scheduling based on processor functions to switch the implementation of a complex numerical algorithm. I want to include two versions (sse2 and sse3 for arguments) I am compiling in the same dynamic library.

The approach taken so far is to wrap all architecture-specific code in a namespace, for example. namespace sse2 and namespace sse3 and thus avoiding duplicate symbol names when linking to the destination dynamic library.

However, what happens if I use some code outside my control (for example, a std::vector<int> ) in both versions of sse2 and ss3. As far as I can see, the std::vector implementation will be present both in the sse2 and sse3 object files, but theoretically it may contain different instructions depending on the optimizations performed by the compiler. When I link these object files in a dynamic library, one of them will be used, and I risk potentially trying to run the sse3 instruction on the processor, supporting only sse2.

Besides compiling into two separate dynamic libraries, what can be done to get around this problem? I need a solution that works with both Visual Studio and windows, mac os x and linux.

Answer 1

One approach is to send at the shared library level instead of the object file level. This would require compiling the entire library several times with support for various instructions, and then sending it to the appropriate shared library at runtime based on the CPU capabilities you discovered. I detail the approach that might work for this on OS X and Linux in this previous answer . However, I did not try to implement this on Windows (however).

Answer 2

This script is fully supported in the language and does not require any explicit processing. The dynamic distribution scenario has nothing to do with it - it is very typical for a project to create an instance of std :: vector in several translation units, and ODR is not violated. In general, built-in functions - and, in particular, template instances - are simply not visible to the linker (i.e., they do not appear as "external" in the obj file tables).

If for some exotic reason you need to explicitly control this type of connection, you will have to resort to a compiler. The MSVC selectany device , gcc has some other devices . I do not know about clang - but the fact is that it will be difficult for you to come up with a reason to use any of them.