search for: __atomic_

...ins, which clang lowers directly to atomic IR instructions. Then, the llvm atomic IR instructions themselves can sometimes emit libcalls to __sync_* library functions (which are basically undocumented, and users are often responsible for implementing themselves if they need it). There's the new __atomic_* builtins, which clang will, depending on size and alignment and target, lower either to a libcall to a "standardized-by-GCC <https://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary>" __atomic_* library function (implemented by libatomic), or, to the atomic IR instructions. (Also covered by t...

...atomic IR instructions. Then, the llvm atomic IR instructions > themselves can sometimes emit libcalls to __sync_* library > functions (which are basically undocumented, and users are often > responsible for implementing themselves if they need it). > 2. There's the new __atomic_* builtins, which clang will, depending > on size and alignment and target, lower either to a libcall to a > "standardized-by-GCC > <https://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary>" __atomic_* > library function (implemented by libatomic), or, to the atomic...

...structions. Then, the llvm atomic IR > instructions themselves can sometimes emit libcalls to __sync_* > library functions (which are basically undocumented, and users > are often responsible for implementing themselves if they need > it). > 2. There's the new __atomic_* builtins, which clang will, > depending on size and alignment and target, lower either to a > libcall to a " standardized-by-GCC " __atomic_* library function > (implemented by libatomic), or, to the atomic IR instructions. > (Also covered by the same code is...

...;d like to add HLE support in LLVM/clang consistent to GCC's style [1]. HLE from Intel TSX [2] is legacy compatible instruction set extension to specify transactional region by adding XACQUIRE and XRELEASE prefixes. To support that, GCC chooses the approach by extending the memory order flag in __atomic_* builtins with target-specific memory model in high bits (bit 31-16 for target-specific memory model, bit 15-0 for the general memory model.) To follow the similar approach, I propose to change LLVM/clang by adding: + a metadata 'targetflags' in LLVM atomic IR to pass this target-specifi...

...upport in LLVM/clang consistent to GCC's style [1]. > HLE from Intel TSX [2] is legacy compatible instruction set extension to > specify transactional region by adding XACQUIRE and XRELEASE prefixes. > To support that, GCC chooses the approach by extending the memory order > flag in __atomic_* builtins with target-specific memory model in high > bits (bit 31-16 for target-specific memory model, bit 15-0 for the > general memory model.) To follow the similar approach, I propose to > change LLVM/clang by adding: > > + a metadata 'targetflags' in LLVM atomic IR to p...

...upport in LLVM/clang consistent to GCC's style [1]. > HLE from Intel TSX [2] is legacy compatible instruction set extension to > specify transactional region by adding XACQUIRE and XRELEASE prefixes. > To support that, GCC chooses the approach by extending the memory order > flag in __atomic_* builtins with target-specific memory model in high > bits (bit 31-16 for target-specific memory model, bit 15-0 for the > general memory model.) To follow the similar approach, I propose to > change LLVM/clang by adding: > > + a metadata 'targetflags' in LLVM atomic IR to p...

...upport in LLVM/clang consistent to GCC's style [1]. > HLE from Intel TSX [2] is legacy compatible instruction set extension to > specify transactional region by adding XACQUIRE and XRELEASE prefixes. > To support that, GCC chooses the approach by extending the memory order > flag in __atomic_* builtins with target-specific memory model in high > bits (bit 31-16 for target-specific memory model, bit 15-0 for the > general memory model.) To follow the similar approach, I propose to > change LLVM/clang by adding: > > + a metadata 'targetflags' in LLVM atomic IR to p...

...;d like to add HLE support in LLVM/clang consistent to GCC's style [1]. HLE from Intel TSX [2] is legacy compatible instruction set extension to specify transactional region by adding XACQUIRE and XRELEASE prefixes. To support that, GCC chooses the approach by extending the memory order flag in __atomic_* builtins with target-specific memory model in high bits (bit 31-16 for target-specific memory model, bit 15-0 for the general memory model.) To follow the similar approach, I propose to change LLVM/clang by adding: + a metadata 'targetflags' in LLVM atomic IR to pass this target-specifi...

...add HLE support in LLVM/clang consistent to GCC's style [1]. HLE from Intel TSX [2] is legacy compatible instruction set extension to > specify transactional region by adding XACQUIRE and XRELEASE prefixes. To support that, GCC chooses the approach by extending the memory order > flag in __atomic_* builtins with target-specific memory model in high bits (bit 31-16 for target-specific memory model, bit 15-0 for the general memory model.) To follow the similar approach, I propose to > change LLVM/clang by adding: > > + a metadata 'targetflags' in LLVM atomic IR to pass this &...

...support in LLVM/clang consistent to GCC's style [1]. HLE from Intel TSX [2] is legacy compatible instruction set extension to >> specify transactional region by adding XACQUIRE and XRELEASE prefixes. To support that, GCC chooses the approach by extending the memory order >> flag in __atomic_* builtins with target-specific memory model in high bits (bit 31-16 for target-specific memory model, bit 15-0 for the general memory model.) To follow the similar approach, I propose to >> change LLVM/clang by adding: >> >> + a metadata 'targetflags' in LLVM atomic IR to...

On Thu, Jan 28, 2016 at 08:32:31AM -0800, Reid Kleckner via llvm-dev wrote: > I think Clang should continue to duplicate this information, the same way > we duplicate target datalayout strings. Other than that, sure, we can let > LLVM expand IR operations to libcalls. I don't immediately see a problem > with that. Note that a libcall doesn't necessarily mean using locks. With