maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/Transforms/GlobalOpt/atomic.ll

26 lines
541 B
LLVM
Raw Normal View History

Teach GlobalOpt to handle atomic accesses to globals. * Most of the transforms come through intact by having each transformed load or store copy the ordering and synchronization scope of the original. * The transform that turns a global only accessed in main() into an alloca (since main is non-recursive) with a store of the initial value uses an unordered store, since it's guaranteed to be the first thing to happen in main. (Threads may have started before main (!) but they can't have the address of a function local before the point in the entry block we insert our code.) * The heap-SRoA transforms are disabled in the face of atomic operations. This can probably be improved; it seems odd to have atomic accesses to an alloca that doesn't have its address taken. AnalyzeGlobal keeps track of the strongest ordering found in any use of the global. This is more information than we need right now, but it's cheap to compute and likely to be useful. llvm-svn: 149847
2012-02-06 03:56:38 +08:00
; RUN: opt -globalopt < %s -S -o - | FileCheck %s
@GV1 = internal global i64 1
Don't shrink atomic ops to bool in GlobalOpt. LLVM IR doesn't currently allow atomic bool load/store operations, and the transformation is dubious anyway because it isn't profitable on all platforms. PR17163. llvm-svn: 190357
2013-09-10 06:00:13 +08:00
@GV2 = internal global i32 0
Revert r193251 : Use address-taken to disambiguate global variable and indirect memops. llvm-svn: 193489
2013-10-27 11:08:44 +08:00
; CHECK: @GV1 = internal unnamed_addr constant i64 1
; CHECK: @GV2 = internal unnamed_addr global i32 0
Teach GlobalOpt to handle atomic accesses to globals. * Most of the transforms come through intact by having each transformed load or store copy the ordering and synchronization scope of the original. * The transform that turns a global only accessed in main() into an alloca (since main is non-recursive) with a store of the initial value uses an unordered store, since it's guaranteed to be the first thing to happen in main. (Threads may have started before main (!) but they can't have the address of a function local before the point in the entry block we insert our code.) * The heap-SRoA transforms are disabled in the face of atomic operations. This can probably be improved; it seems odd to have atomic accesses to an alloca that doesn't have its address taken. AnalyzeGlobal keeps track of the strongest ordering found in any use of the global. This is more information than we need right now, but it's cheap to compute and likely to be useful. llvm-svn: 149847
2012-02-06 03:56:38 +08:00
define void @test1() {
entry:
%0 = load atomic i8* bitcast (i64* @GV1 to i8*) acquire, align 8
ret void
}
Don't shrink atomic ops to bool in GlobalOpt. LLVM IR doesn't currently allow atomic bool load/store operations, and the transformation is dubious anyway because it isn't profitable on all platforms. PR17163. llvm-svn: 190357
2013-09-10 06:00:13 +08:00
; PR17163
define void @test2a() {
entry:
store atomic i32 10, i32* @GV2 seq_cst, align 4
ret void
}
define i32 @test2b() {
entry:
%atomic-load = load atomic i32* @GV2 seq_cst, align 4
ret i32 %atomic-load
}