3 ms·
This is standardizing vendor-specific attributes that have existed for many years. The code that use these probably use some preprocessor macro to select the r
by omoikane 3y ago
This is standardizing vendor-specific attributes that have existed for many years. The code that use these probably use some preprocessor macro to select the right builtins, and aren't going to gain much new clutter to replace those macros.
I believe this is the proposal that added them:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0479r0.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p04...
The "references" section has links to GCC and Clang builtins:
https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html
http://llvm.org/docs/BranchWeightMetadata.html#built-in-expect-instructions http://llvm.org/docs/BranchWeightMetadata.html#built-in-expe...
- cpeterso 3y ago> This is standardizing vendor-specific attributes Except the standard’s likely and unlikely attributes invented new syntax that is not drop-in compatible with clang’s and gcc’s attributes. Where clang and gcc would use: if (__builtin_expect(x > 0, 1)) { … } the standard uses: if (x > 0) [[likely]] { … }
- ack_complete 3y agoIt's definitely an unconventional syntax. In addition to the above, OpenMP and shader languages annotate the branch statement for parallelism or branch/predication hints. I can't think of precedent for C++ putting the hints in the branch targets. It does have some advantages, but it's not very intuitive. The first time I tried to use the new hints I did [[likely]] if(), which of course did nothing.
- JonChesterfield 3y agoDoesn't look like it. The attribute goes on branches. This goes in the middle of basic blocks. Doesn't seem better to me, might try to find the rationale for the invention instead of standardising existing practice. That proposal shows the existing attributes with different syntax.