replica
/
hanchenye-llvm-project
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
hanchenye-llvm-project/llvm/test/Transforms/GlobalOpt/invoke.ll

28 lines
728 B
LLVM
Raw Normal View History

Teach globalopt how to evaluate an invoke with a non-void return type. llvm-svn: 152634
2012-03-14 02:01:37 +08:00
; RUN: opt -S -globalopt < %s | FileCheck %s
; rdar://11022897
; Globalopt should be able to evaluate an invoke.
IR: Introduce local_unnamed_addr attribute. If a local_unnamed_addr attribute is attached to a global, the address is known to be insignificant within the module. It is distinct from the existing unnamed_addr attribute in that it only describes a local property of the module rather than a global property of the symbol. This attribute is intended to be used by the code generator and LTO to allow the linker to decide whether the global needs to be in the symbol table. It is possible to exclude a global from the symbol table if three things are true: - This attribute is present on every instance of the global (which means that the normal rule that the global must have a unique address can be broken without being observable by the program by performing comparisons against the global's address) - The global has linkonce_odr linkage (which means that each linkage unit must have its own copy of the global if it requires one, and the copy in each linkage unit must be the same) - It is a constant or a function (which means that the program cannot observe that the unique-address rule has been broken by writing to the global) Although this attribute could in principle be computed from the module contents, LTO clients (i.e. linkers) will normally need to be able to compute this property as part of symbol resolution, and it would be inefficient to materialize every module just to compute it. See: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html for earlier discussion. Part of the fix for PR27553. Differential Revision: http://reviews.llvm.org/D20348 llvm-svn: 272709
2016-06-15 05:01:22 +08:00
; CHECK: @tmp = local_unnamed_addr global i32 1
Teach globalopt how to evaluate an invoke with a non-void return type. llvm-svn: 152634
2012-03-14 02:01:37 +08:00
@llvm.global_ctors = appending global [1 x { i32, void ()* }] [{ i32, void ()* } { i32 65535, void ()* @_GLOBAL__I_a }]
@tmp = global i32 0
define i32 @one() {
ret i32 1
}
Move the personality function from LandingPadInst to Function The personality routine currently lives in the LandingPadInst. This isn't desirable because: - All LandingPadInsts in the same function must have the same personality routine. This means that each LandingPadInst beyond the first has an operand which produces no additional information. - There is ongoing work to introduce EH IR constructs other than LandingPadInst. Moving the personality routine off of any one particular Instruction and onto the parent function seems a lot better than have N different places a personality function can sneak onto an exceptional function. Differential Revision: http://reviews.llvm.org/D10429 llvm-svn: 239940
2015-06-18 04:52:32 +08:00
define void @_GLOBAL__I_a() personality i8* undef {
Teach globalopt how to evaluate an invoke with a non-void return type. llvm-svn: 152634
2012-03-14 02:01:37 +08:00
bb:
%tmp1 = invoke i32 @one()
to label %bb2 unwind label %bb4
bb2: ; preds = %bb
store i32 %tmp1, i32* @tmp
ret void
bb4: ; preds = %bb
Move the personality function from LandingPadInst to Function The personality routine currently lives in the LandingPadInst. This isn't desirable because: - All LandingPadInsts in the same function must have the same personality routine. This means that each LandingPadInst beyond the first has an operand which produces no additional information. - There is ongoing work to introduce EH IR constructs other than LandingPadInst. Moving the personality routine off of any one particular Instruction and onto the parent function seems a lot better than have N different places a personality function can sneak onto an exceptional function. Differential Revision: http://reviews.llvm.org/D10429 llvm-svn: 239940
2015-06-18 04:52:32 +08:00
%tmp5 = landingpad { i8*, i32 }
Teach globalopt how to evaluate an invoke with a non-void return type. llvm-svn: 152634
2012-03-14 02:01:37 +08:00
filter [0 x i8*] zeroinitializer
unreachable
}