maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/ThinLTO/X86/personality.ll

80 lines
2.2 KiB
LLVM
Raw Normal View History

[lib/Analysis] - Mark personality functions as live. This is PR33245. Case I am fixing is next: Imagine we have 2 BC files, one defines and uses personality routine, second has only declaration and also uses it. Previously algorithm computing dead symbols (llvm::computeDeadSymbols) did not know about personality routines and leaved them dead even if function that has routine was live. As a result thinLTOInternalizeAndPromoteGUID() method changed binding for such symbol to local. Later when LLD tried to link these objects it failed because one object had undefined global symbol for routine and second object contained local definition instead of global. Patch set the live root flag on the corresponding FunctionSummary for personality routines when we build the per-module summaries during the compile step. Differential revision: https://reviews.llvm.org/D36834 llvm-svn: 311432
2017-08-22 16:50:56 +08:00
; RUN: opt -module-summary %s -o %t1.bc
; RUN: opt -module-summary %S/Inputs/personality.ll -o %t2.bc
; RUN: llvm-lto2 run -o %t.o %t1.bc %t2.bc -save-temps \
; RUN: -r %t2.bc,bar,p \
; RUN: -r %t2.bc,personality_routine,p \
ModuleSummaryAnalysis: Correctly handle all function operand references. The current code that handles personality functions when creating a module summary does not correctly handle the case where a function's personality function operand refers to the function indirectly (e.g. via a bitcast). This patch handles such cases by treating personality function references like any other reference, i.e. by adding them to the function's reference list. This has the minor side benefit of allowing personality functions to participate in early dead stripping. We do this by calling findRefEdges on the function itself. This way we also end up handling other function operands (specifically prefix data and prologue data) for free. Differential Revision: https://reviews.llvm.org/D37553 llvm-svn: 312698
2017-09-07 13:35:35 +08:00
; RUN: -r %t2.bc,personality_routine2,p \
; RUN: -r %t2.bc,personality_routine3,p \
[lib/Analysis] - Mark personality functions as live. This is PR33245. Case I am fixing is next: Imagine we have 2 BC files, one defines and uses personality routine, second has only declaration and also uses it. Previously algorithm computing dead symbols (llvm::computeDeadSymbols) did not know about personality routines and leaved them dead even if function that has routine was live. As a result thinLTOInternalizeAndPromoteGUID() method changed binding for such symbol to local. Later when LLD tried to link these objects it failed because one object had undefined global symbol for routine and second object contained local definition instead of global. Patch set the live root flag on the corresponding FunctionSummary for personality routines when we build the per-module summaries during the compile step. Differential revision: https://reviews.llvm.org/D36834 llvm-svn: 311432
2017-08-22 16:50:56 +08:00
; RUN: -r %t1.bc,foo,p \
ModuleSummaryAnalysis: Correctly handle all function operand references. The current code that handles personality functions when creating a module summary does not correctly handle the case where a function's personality function operand refers to the function indirectly (e.g. via a bitcast). This patch handles such cases by treating personality function references like any other reference, i.e. by adding them to the function's reference list. This has the minor side benefit of allowing personality functions to participate in early dead stripping. We do this by calling findRefEdges on the function itself. This way we also end up handling other function operands (specifically prefix data and prologue data) for free. Differential Revision: https://reviews.llvm.org/D37553 llvm-svn: 312698
2017-09-07 13:35:35 +08:00
; RUN: -r %t1.bc,foo2,p \
; RUN: -r %t1.bc,foo3,p \
[lib/Analysis] - Mark personality functions as live. This is PR33245. Case I am fixing is next: Imagine we have 2 BC files, one defines and uses personality routine, second has only declaration and also uses it. Previously algorithm computing dead symbols (llvm::computeDeadSymbols) did not know about personality routines and leaved them dead even if function that has routine was live. As a result thinLTOInternalizeAndPromoteGUID() method changed binding for such symbol to local. Later when LLD tried to link these objects it failed because one object had undefined global symbol for routine and second object contained local definition instead of global. Patch set the live root flag on the corresponding FunctionSummary for personality routines when we build the per-module summaries during the compile step. Differential revision: https://reviews.llvm.org/D36834 llvm-svn: 311432
2017-08-22 16:50:56 +08:00
; RUN: -r %t1.bc,personality_routine,l \
ModuleSummaryAnalysis: Correctly handle all function operand references. The current code that handles personality functions when creating a module summary does not correctly handle the case where a function's personality function operand refers to the function indirectly (e.g. via a bitcast). This patch handles such cases by treating personality function references like any other reference, i.e. by adding them to the function's reference list. This has the minor side benefit of allowing personality functions to participate in early dead stripping. We do this by calling findRefEdges on the function itself. This way we also end up handling other function operands (specifically prefix data and prologue data) for free. Differential Revision: https://reviews.llvm.org/D37553 llvm-svn: 312698
2017-09-07 13:35:35 +08:00
; RUN: -r %t1.bc,personality_routine2,l \
; RUN: -r %t1.bc,personality_routine3,l \
[lib/Analysis] - Mark personality functions as live. This is PR33245. Case I am fixing is next: Imagine we have 2 BC files, one defines and uses personality routine, second has only declaration and also uses it. Previously algorithm computing dead symbols (llvm::computeDeadSymbols) did not know about personality routines and leaved them dead even if function that has routine was live. As a result thinLTOInternalizeAndPromoteGUID() method changed binding for such symbol to local. Later when LLD tried to link these objects it failed because one object had undefined global symbol for routine and second object contained local definition instead of global. Patch set the live root flag on the corresponding FunctionSummary for personality routines when we build the per-module summaries during the compile step. Differential revision: https://reviews.llvm.org/D36834 llvm-svn: 311432
2017-08-22 16:50:56 +08:00
; RUN: -r %t1.bc,main,xp \
; RUN: -r %t1.bc,bar,l
; RUN: llvm-readobj -t %t.o.1 | FileCheck %s --check-prefix=BINDING
; BINDING: Symbol {
; BINDING: Name: personality_routine
; BINDING-NEXT: Value:
; BINDING-NEXT: Size:
; BINDING-NEXT: Binding: Global
; BINDING-NEXT: Type: Function
; BINDING-NEXT: Other [
; BINDING-NEXT: STV_PROTECTED
; BINDING-NEXT: ]
; BINDING-NEXT: Section: .text
; BINDING-NEXT: }
ModuleSummaryAnalysis: Correctly handle all function operand references. The current code that handles personality functions when creating a module summary does not correctly handle the case where a function's personality function operand refers to the function indirectly (e.g. via a bitcast). This patch handles such cases by treating personality function references like any other reference, i.e. by adding them to the function's reference list. This has the minor side benefit of allowing personality functions to participate in early dead stripping. We do this by calling findRefEdges on the function itself. This way we also end up handling other function operands (specifically prefix data and prologue data) for free. Differential Revision: https://reviews.llvm.org/D37553 llvm-svn: 312698
2017-09-07 13:35:35 +08:00
; BINDING-NEXT: Symbol {
; BINDING-NEXT: Name: personality_routine2
; BINDING-NEXT: Value:
; BINDING-NEXT: Size:
; BINDING-NEXT: Binding: Global
; BINDING-NEXT: Type: Function
; BINDING-NEXT: Other [
; BINDING-NEXT: STV_PROTECTED
; BINDING-NEXT: ]
; BINDING-NEXT: Section: .text
; BINDING-NEXT: }
; BINDING-NOT: Name: personality_routine3
[lib/Analysis] - Mark personality functions as live. This is PR33245. Case I am fixing is next: Imagine we have 2 BC files, one defines and uses personality routine, second has only declaration and also uses it. Previously algorithm computing dead symbols (llvm::computeDeadSymbols) did not know about personality routines and leaved them dead even if function that has routine was live. As a result thinLTOInternalizeAndPromoteGUID() method changed binding for such symbol to local. Later when LLD tried to link these objects it failed because one object had undefined global symbol for routine and second object contained local definition instead of global. Patch set the live root flag on the corresponding FunctionSummary for personality routines when we build the per-module summaries during the compile step. Differential revision: https://reviews.llvm.org/D36834 llvm-svn: 311432
2017-08-22 16:50:56 +08:00
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-pc-linux-gnu"
declare protected i32 @personality_routine(i32, i32, i64, i8*, i8*)
ModuleSummaryAnalysis: Correctly handle all function operand references. The current code that handles personality functions when creating a module summary does not correctly handle the case where a function's personality function operand refers to the function indirectly (e.g. via a bitcast). This patch handles such cases by treating personality function references like any other reference, i.e. by adding them to the function's reference list. This has the minor side benefit of allowing personality functions to participate in early dead stripping. We do this by calling findRefEdges on the function itself. This way we also end up handling other function operands (specifically prefix data and prologue data) for free. Differential Revision: https://reviews.llvm.org/D37553 llvm-svn: 312698
2017-09-07 13:35:35 +08:00
declare protected i32 @personality_routine2(i32, i32, i64, i8*, i8*)
declare protected i32 @personality_routine3(i32, i32, i64, i8*, i8*)
[lib/Analysis] - Mark personality functions as live. This is PR33245. Case I am fixing is next: Imagine we have 2 BC files, one defines and uses personality routine, second has only declaration and also uses it. Previously algorithm computing dead symbols (llvm::computeDeadSymbols) did not know about personality routines and leaved them dead even if function that has routine was live. As a result thinLTOInternalizeAndPromoteGUID() method changed binding for such symbol to local. Later when LLD tried to link these objects it failed because one object had undefined global symbol for routine and second object contained local definition instead of global. Patch set the live root flag on the corresponding FunctionSummary for personality routines when we build the per-module summaries during the compile step. Differential revision: https://reviews.llvm.org/D36834 llvm-svn: 311432
2017-08-22 16:50:56 +08:00
declare void @bar()
define void @foo() personality i32 (i32, i32, i64, i8*, i8*)* @personality_routine {
ret void
}
ModuleSummaryAnalysis: Correctly handle all function operand references. The current code that handles personality functions when creating a module summary does not correctly handle the case where a function's personality function operand refers to the function indirectly (e.g. via a bitcast). This patch handles such cases by treating personality function references like any other reference, i.e. by adding them to the function's reference list. This has the minor side benefit of allowing personality functions to participate in early dead stripping. We do this by calling findRefEdges on the function itself. This way we also end up handling other function operands (specifically prefix data and prologue data) for free. Differential Revision: https://reviews.llvm.org/D37553 llvm-svn: 312698
2017-09-07 13:35:35 +08:00
define internal void @foo2b() personality i8* bitcast (i32 (i32, i32, i64, i8*, i8*)* @personality_routine2 to i8*) {
ret void
}
define internal void @foo2a() prologue void ()* @foo2b {
ret void
}
define void @foo2() prefix void ()* @foo2a {
ret void
}
define void @foo3() personality i8* bitcast (i32 (i32, i32, i64, i8*, i8*)* @personality_routine3 to i8*) {
ret void
}
[lib/Analysis] - Mark personality functions as live. This is PR33245. Case I am fixing is next: Imagine we have 2 BC files, one defines and uses personality routine, second has only declaration and also uses it. Previously algorithm computing dead symbols (llvm::computeDeadSymbols) did not know about personality routines and leaved them dead even if function that has routine was live. As a result thinLTOInternalizeAndPromoteGUID() method changed binding for such symbol to local. Later when LLD tried to link these objects it failed because one object had undefined global symbol for routine and second object contained local definition instead of global. Patch set the live root flag on the corresponding FunctionSummary for personality routines when we build the per-module summaries during the compile step. Differential revision: https://reviews.llvm.org/D36834 llvm-svn: 311432
2017-08-22 16:50:56 +08:00
define i32 @main() {
call void @foo()
ModuleSummaryAnalysis: Correctly handle all function operand references. The current code that handles personality functions when creating a module summary does not correctly handle the case where a function's personality function operand refers to the function indirectly (e.g. via a bitcast). This patch handles such cases by treating personality function references like any other reference, i.e. by adding them to the function's reference list. This has the minor side benefit of allowing personality functions to participate in early dead stripping. We do this by calling findRefEdges on the function itself. This way we also end up handling other function operands (specifically prefix data and prologue data) for free. Differential Revision: https://reviews.llvm.org/D37553 llvm-svn: 312698
2017-09-07 13:35:35 +08:00
call void @foo2()
[lib/Analysis] - Mark personality functions as live. This is PR33245. Case I am fixing is next: Imagine we have 2 BC files, one defines and uses personality routine, second has only declaration and also uses it. Previously algorithm computing dead symbols (llvm::computeDeadSymbols) did not know about personality routines and leaved them dead even if function that has routine was live. As a result thinLTOInternalizeAndPromoteGUID() method changed binding for such symbol to local. Later when LLD tried to link these objects it failed because one object had undefined global symbol for routine and second object contained local definition instead of global. Patch set the live root flag on the corresponding FunctionSummary for personality routines when we build the per-module summaries during the compile step. Differential revision: https://reviews.llvm.org/D36834 llvm-svn: 311432
2017-08-22 16:50:56 +08:00
call void @bar()
ret i32 0
}