MSVC вот такого не любит:

constexpr int32_t pop_count(uint32_t v)
{
    return __popcnt(v);
}

а вот GCC такое вполне устраивает:

constexpr int32_t pop_count(uint32_t v)
{
    return __builtin_popcount(v);
}

Кто как выкручивается с микрософтовским компилятором?

Здравствуйте, andyp, Вы писали:

A>Кто как выкручивается с микрософтовским компилятором?

Так как делать перегрузку на основе constexpr пока нельзя, то пришлось забить на красоту и просто сделать две функции: pop_count и pop_count_at_compile_time. Первая работает через интринсик (и разворачивается в одну инструкцию процессора), а вторая просто реализует один из классических алгоритмов подсчёта.

Здравствуйте, andyp, Вы писали:

A>MSVC вот такого не любит:

С MS понятно — интринсики это API к инструкциям процессора, а это не compile-time, очевидно.
Тут, скорее, вопрос к GCC — у них все интринсики разворачиваются компилятором или только часть?

Здравствуйте, flаt, Вы писали:

F>С MS понятно — интринсики это API к инструкциям процессора, а это не compile-time, очевидно.
с чего вы взяли?
читаем: https://msdn.microsoft.com/en-us/library/26td21ds.aspx

Здравствуйте, flаt, Вы писали:

F>С MS понятно — интринсики это API к инструкциям процессора, а это не compile-time, очевидно.
F>Тут, скорее, вопрос к GCC — у них все интринсики разворачиваются компилятором или только часть?

Судя по комментариям к библиотеке folly, микрософт в смысле интринсиков после 2015 пойдет по пути gcc — они будут доступны во время компиляции. Что касается времени выполнения, то gcc вставляет разные реализации builtin функций в зависимости от архитектуры, под которую собираешь — это может быть как одна ассемблерная команда, так и кусочек кода. На счет того, какие интринсики gcc недоступны во время компиляции — не знаю. Например, builtin_popcount точно доступен, как и другие битовые операции типа count leading zeros.