Namespace internal

Description

No description yet.

Classes

atomic_base_width
atomic_integral_base
atomic_integral_width
atomic_invalid_type
atomic_pointer_base
atomic_pointer_base< T *, width >
atomic_pointer_width
atomic_size_aligned
FixedWidth128
function_base_detailfunction_base_detail
function_detailfunction_detail
function_detail< SIZE_IN_BYTES, R(Args...)>
functor_storage
functor_storage< 0 >
functor_storage_alignment
is_atomic_lockfree_size
is_fixed_function
is_fixed_function< eastl::fixed_function< SIZE_IN_BYTES, R(Args...)> >
is_functor_inplace_allocatable
is_user_type_suitable_for_primary_template
memory_order_acq_rel_s
memory_order_acquire_s
memory_order_read_depends_s
memory_order_relaxed_s
memory_order_release_s
memory_order_seq_cst_s
unused_class

Functions

AtomicIntegralCast
AtomicNegateOperand overload
AtomicTypeCast
AtomicTypePunCastNOTE:
AtomicVolatileCast
AtomicVolatileIntegralCastNOTE:
AtomicVolatileTypeCastNOTE:
EastlCompilerBarrierDataDependencyFunc
is_null overloadis_null
to_array overload

Typedefs

Typedefs (atomic.h)

template <typename T>
using select_atomic_inherit_0 = typename eastl::conditional< eastl::is_same_v< bool, T >||eastl::internal::is_user_type_suitable_for_primary_template< T >::value, eastl::internal::atomic_base_width< T >, eastl::internal::atomic_invalid_type< T > >::type

template <typename T>
using select_atomic_inherit = select_atomic_inherit_0< T >

Typedefs (compiler.h)

typedef void(* CompilerBarrierDataDependencyFuncPtr)(void *)

NOTE:

This can be used by specific compiler implementations to implement a data dependency compiler barrier. Some compiler barriers do not take in input dependencies as is possible with the gcc asm syntax. Thus we need a way to create a false dependency on the input variable so the compiler does not dead-store remove it. A volatile function pointer ensures the compiler must always load the function pointer and call thru it since the compiler cannot reason about any side effects. Thus the compiler must always assume the input variable may be accessed and thus cannot be dead-stored. This technique works even in the presence of Link-Time Optimization. A compiler barrier with a data dependency is useful in these situations.

void foo() { eastl::vector<int> v; while (Benchmark.ContinueRunning()) { v.push_back(0); eastl::compiler_barrier(); OR eastl::compiler_barrier_data_dependency(v); } }

We are trying to benchmark the push_back function of a vector. The vector v has only local scope. The compiler is well within its writes to remove all accesses to v even with the compiler barrier because there are no observable uses of the vector v. The compiler barrier data dependency ensures there is an input dependency on the variable so that it isn't removed. This is also useful when writing test code that the compiler may remove.

Variables

Variables (fixed_function.h)

template <typename T>
EA_CONSTEXPR bool is_fixed_function_v = is_fixed_function<T>::value

Variables (compiler.h)

EASTL_API volatile CompilerBarrierDataDependencyFuncPtr gCompilerBarrierDataDependencyFunc = &EastlCompilerBarrierDataDependencyFunc

Source

Line 485 in include/EASTL/array.h.






Add Discussion as Guest

Log in