|
Revision tags: v2021.12.0-rc1, v2021.4.1, v2021.11.0, v2021.2.4, v2021.11.0-rc1 |
|
| #
e1310717 |
| 11-Sep-2023 |
Dmitri Mokhov <[email protected]> |
Fix/suppress new GCC 12/13 warnings (#1192)
Signed-off-by: Dmitri Mokhov <[email protected]>
|
|
Revision tags: v2021.11.0-src-rc1, v2021.2.3, v2021.10.0, v2021.10.0-rc1, v2020.3.3, v2021.2.2, v2021.9.0, v2021.2.1, v2021.9.0-rc1, v2020.3.2, v2021.8.0, v2021.8.0-rc1, v2020.3.1, v2021.7.0, v2021.7.0-rc1, v2021.6.0, v2021.6.0-rc1 |
|
| #
8a874694 |
| 22-Dec-2021 |
Andrey Semashev <[email protected]> |
Optimize x86 atomic_fence (#328)
* Added optimized x86 atomic_fence for gcc-compatible compilers.
On x86 (32 and 64-bit) any lock-prefixed instruction provides sequential
consistency guarantees
Optimize x86 atomic_fence (#328)
* Added optimized x86 atomic_fence for gcc-compatible compilers.
On x86 (32 and 64-bit) any lock-prefixed instruction provides sequential
consistency guarantees for atomic operations and is more efficient than
mfence.
We are choosing a "lock not" on a dummy byte on the stack for the following
reasons:
- The "not" instruction does not affect flags or clobber any registers.
The memory operand is presumably accessible through esp/rsp.
- The dummy byte variable is at the top of the stack, which is likely
hot in cache.
- The dummy variable does not alias any other data on the stack, which
means the "lock not" instruction won't introduce any false data
dependencies with prior or following instructions.
In order to avoid various sanitizers and valgrind complaining, we have to
initialize the dummy variable to zero prior to the operation.
Additionally, for memory orders weaker than seq_cst there is no need for
any special instructions, and we only need a compiler fence. For the relaxed
memory order we don't need even that.
This optimization is only enabled for gcc up to version 11. In gcc 11 the
compiler implements a similar optimization for std::atomic_thread_fence.
Compilers compatible with gcc (namely, clang up to 13 and icc up to 2021.3.0,
inclusively) identify themselves as gcc < 11 and also benefit from this
optimization, as they otherwise generate mfence for
std::atomic_thread_fence(std::memory_order_seq_cst).
Signed-off-by: Andrey Semashev <[email protected]>
* Removed explicit mfence in atomic_fence on Windows.
The necessary instructions according to the memory order argument
should already be generated by std::atomic_thread_fence.
Signed-off-by: Andrey Semashev <[email protected]>
* Removed memory order argument from atomic_fence.
The code uses memory_order_seq_cst in all call sites of atomic_fence,
so remove the argument and simplifiy the implementation a bit. Also, renamed
the function to make the memory order it implements apparent.
Signed-off-by: Andrey Semashev <[email protected]>
show more ...
|
|
Revision tags: v2021.5.0 |
|
| #
ba947f18 |
| 21-Oct-2021 |
Ilya Isaev <[email protected]> |
Changes in code after applying some clang-tidy check fixes (#620)
Applied fixes from clang-tidy(readability and modernize)
Signed-off-by: Ilya Isaev [email protected]
|
|
Revision tags: v2021.5.0-rc2, v2021.5.0-rc1, v2021.4.0, v2021.4.0-rc1, v2021.3.0 |
|
| #
478de5b1 |
| 05-May-2021 |
tbbdev <[email protected]> |
Commit oneTBB source code 82ff8707
|
| #
4523a761 |
| 01-Mar-2021 |
tbbdev <[email protected]> |
Commit oneTBB source code 4fcd448a
|
|
Revision tags: v2021.2.0, v2021.2.0-rc |
|
| #
b15aabb3 |
| 26-Jan-2021 |
tbbdev <[email protected]> |
Commit oneTBB source code 9ed4a21c
|
|
Revision tags: v2021.1.1 |
|
| #
8dcbd5b1 |
| 18-Nov-2020 |
tbbdev <[email protected]> |
Commit oneTBB source code 8fda6294
|
| #
49e08aac |
| 28-Oct-2020 |
tbbdev <[email protected]> |
Commit oneTBB source code 6420d97a
|
|
Revision tags: v2021.1-beta10 |
|
| #
51c0b2f7 |
| 25-Sep-2020 |
tbbdev <[email protected]> |
Commit oneTBB source code 4ebd2d06
|