Unikanie powtarzania symbolu podczas kompilowania do wielu zestawów instrukcji

Question

Jestem w trakcie korzystania z wysyłania procesora w oparciu o funkcje procesora, aby przełączyć implementację skomplikowanego algorytmu numerycznego. Chcę dołączyć dwie wersje (wersję sse2 i sse3 dla argumentów) Kompiluję w tej samej dynamicznej bibliotece.

Dotychczasowe podejście polegało na zawarciu całego kodu architektury do przestrzeni nazw, np. namespace sse2 i namespace sse3 i tym samym unika się powielania nazw symboli podczas łączenia z ostateczną biblioteką dynamiczną.

Co jednak się stanie, jeśli użyję kodu spoza mojej kontroli (np. std::vector<int>) zarówno w wersji sse2, jak i ss3. O ile widzę, implementacja std::vector będzie obecna zarówno w plikach obiektów sse2, jak i sse3, ale teoretycznie może zawierać różne instrukcje w zależności od optymalizacji wykonywanych przez kompilator. Kiedy połączę te pliki obiektów z biblioteką dynamiczną, jedna z nich zostanie wykorzystana i ryzykuję potencjalnie próbą uruchomienia instrukcji sse3 na procesorze obsługującym tylko sse2.

Oprócz kompilacji do dwóch oddzielnych bibliotek dynamicznych, co można zrobić, aby obejść ten problem? Potrzebuję rozwiązania działającego zarówno w Visual Studio, jak i klangu w systemie Windows, Mac OS X i Linux.

Answer 1

Jednym ze sposobów byłoby wysłanie na poziomie biblioteki współdzielonej zamiast poziomu pliku obiektów. Wymagałoby to wielokrotnego kompilowania całej biblioteki przy pomocy różnych zestawów instrukcji, a następnie wysyłania do odpowiedniej biblioteki współdzielonej w czasie wykonywania w zależności od wykrywanych możliwości procesora. Szczegółowo opisuję podejście, które może nad tym pracować w systemie OS X i Linux in this previous answer. Jednak nie próbowałem tego zaimplementować w systemie Windows (jeszcze).

Answer 2

Ten scenariusz jest w pełni obsługiwany w języku i nie powinien wymagać jawnej obsługi. Twój dynamiczny scenariusz wysyłki nie ma z tym wiele wspólnego - bardzo typowe dla projektu jest tworzenie std :: vector w wielu jednostkach tłumaczeniowych, a mimo to ODR nie jest naruszany. Zasadniczo funkcje śródliniowe - aw szczególności instancje szablonów - są po prostu niewidoczne dla łącznika (tj. Nie pojawiają się jako "Zewnętrzne" w tabelach plików obj).

Jeśli z jakiegoś egzotycznego powodu musiałbyś jawnie kontrolować ten typ powiązania, musiałbyś uciekać się do aparatu specyficznego dla kompilatora. Aparat MSVC to selectany, gcc ma some other devices. Nie wiem o klangu - ale chodzi o to, że trudno byłoby wymyślić powód, by użyć któregoś z nich.