Re: Using POPCNT and other advanced bit manipulation instructions
От | Tom Lane |
---|---|
Тема | Re: Using POPCNT and other advanced bit manipulation instructions |
Дата | |
Msg-id | 16168.1550121890@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Using POPCNT and other advanced bit manipulation instructions (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Using POPCNT and other advanced bit manipulation instructions
|
Список | pgsql-hackers |
Some further thoughts here ... Does the "lzcnt" runtime probe actually do anything useful? On the x86_64 compilers I tried (gcc 8.2.1 and 4.4.7), __builtin_clz and __builtin_ctz compile to sequences involving bsrq and bsfq regardless of -mpopcnt. It's fairly hard to see how lzcnt would buy anything over those sequences even if there were zero overhead involved in using it. Alvaro noted that the test programs used by c-compiler.m4 fail to produce any actual code involving the builtin, because of compile-time constant folding. This seems pretty unwise. I see that on my x86_64 compilers, without -mpopcnt, __builtin_popcnt compiles to a call of some libgcc function or other. It's conceivable that on an (arguably misconfigured) platform, these c-compiler.m4 tests would pass yet the build fails at link because libgcc lacks the needed infrastructure. These tests should be coded in a way that doesn't allow the call to be optimized away -- cf comments for PGAC_C_BUILTIN_OP_OVERFLOW. Also, it's starting to seem like we have enough probes for compiler builtins that we should fold them to use one set of infrastructure. There are some like __builtin_constant_p that probably do need their own custom tests, but these ones that just verify that a call compiles seem pretty duplicative ... regards, tom lane
В списке pgsql-hackers по дате отправления: