[PowerPC] Fix logic dealing with nop after calls (and tail-call eligibility)
This change aims to unify and correct our logic for when we need to allow for
the possibility of the linker adding a TOC restoration instruction after a
call. This comes up in two contexts:
1. When determining tail-call eligibility. If we make a tail call (i.e.
directly branch to a function) then there is no place for the linker to add
a TOC restoration.
2. When determining when we need to add a nop instruction after a call.
Likewise, if there is a possibility that the linker might need to add a
TOC restoration after a call, then we need to put a nop after the call
(the bl instruction).
First problem: We were using similar, but different, logic to decide (1) and
(2). This is just wrong. Both the resideInSameModule function (used when
determining tail-call eligibility) and the isLocalCall function (used when
deciding if the post-call nop is needed) were supposed to be determining the
same underlying fact (i.e. might a TOC restoration be needed after the call).
The same logic should be used in both places.
Second problem: The logic in both places was wrong. We only know that two
functions will share the same TOC when both functions come from the same
section of the same object. Otherwise the linker might cause the functions to
use different TOC base addresses (unless the multi-TOC linker option is
disabled, in which case only shared-library boundaries are relevant). There are
a number of factors that can cause functions to be placed in different sections
or come from different objects (-ffunction-sections, explicitly-specified
section names, COMDAT, weak linkage, etc.). All of these need to be checked.
The existing logic only checked properties of the callee, but the properties of
the caller must also be checked (for example, calling from a function in a
COMDAT section means calling between sections).
There was a conceptual error in the resideInSameModule function in that it
allowed tail calls to functions with weak linkage and protected/hidden
visibility. While protected/hidden visibility does prevent the function
implementation from being replaced at runtime (via interposition), it does not
prevent the linker from using an alternate implementation at link time (i.e.
using some strong definition to replace the provided weak one during linking).
If this happens, then we're still potentially looking at a required TOC
restoration upon return.
Otherwise, in general, the post-call nop is needed wherever ELF interposition
needs to be supported. We don't currently support ELF interposition at the IR
level (see http://lists.llvm.org/pipermail/llvm-dev/2016-November/107625.html
for more information), and I don't think we should try to make it appear to
work in the backend in spite of that fact. Unfortunately, because of the way
that the ABI works, we need to generate code as if we supported interposition
whenever the linker might insert stubs for the purpose of supporting it.
Differential Revision: https://reviews.llvm.org/D27231
llvm-svn: 291003
2017-01-05 05:05:13 +08:00
|
|
|
; RUN: llc < %s -relocation-model=pic -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu | FileCheck %s
|
2018-12-05 04:14:57 +08:00
|
|
|
; RUN: llc < %s -relocation-model=pic -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu -mcpu=pwr8 | FileCheck %s
|
|
|
|
|
; RUN: llc < %s -relocation-model=pic -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu -mcpu=pwr8 | FileCheck %s
|
|
|
|
|
; RUN: llc < %s -relocation-model=pic -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu | FileCheck %s
|
|
|
|
|
; RUN: llc < %s -relocation-model=pic -function-sections -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu | FileCheck %s -check-prefix=CHECK-FS
|
[PowerPC] Fix logic dealing with nop after calls (and tail-call eligibility)
This change aims to unify and correct our logic for when we need to allow for
the possibility of the linker adding a TOC restoration instruction after a
call. This comes up in two contexts:
1. When determining tail-call eligibility. If we make a tail call (i.e.
directly branch to a function) then there is no place for the linker to add
a TOC restoration.
2. When determining when we need to add a nop instruction after a call.
Likewise, if there is a possibility that the linker might need to add a
TOC restoration after a call, then we need to put a nop after the call
(the bl instruction).
First problem: We were using similar, but different, logic to decide (1) and
(2). This is just wrong. Both the resideInSameModule function (used when
determining tail-call eligibility) and the isLocalCall function (used when
deciding if the post-call nop is needed) were supposed to be determining the
same underlying fact (i.e. might a TOC restoration be needed after the call).
The same logic should be used in both places.
Second problem: The logic in both places was wrong. We only know that two
functions will share the same TOC when both functions come from the same
section of the same object. Otherwise the linker might cause the functions to
use different TOC base addresses (unless the multi-TOC linker option is
disabled, in which case only shared-library boundaries are relevant). There are
a number of factors that can cause functions to be placed in different sections
or come from different objects (-ffunction-sections, explicitly-specified
section names, COMDAT, weak linkage, etc.). All of these need to be checked.
The existing logic only checked properties of the callee, but the properties of
the caller must also be checked (for example, calling from a function in a
COMDAT section means calling between sections).
There was a conceptual error in the resideInSameModule function in that it
allowed tail calls to functions with weak linkage and protected/hidden
visibility. While protected/hidden visibility does prevent the function
implementation from being replaced at runtime (via interposition), it does not
prevent the linker from using an alternate implementation at link time (i.e.
using some strong definition to replace the provided weak one during linking).
If this happens, then we're still potentially looking at a required TOC
restoration upon return.
Otherwise, in general, the post-call nop is needed wherever ELF interposition
needs to be supported. We don't currently support ELF interposition at the IR
level (see http://lists.llvm.org/pipermail/llvm-dev/2016-November/107625.html
for more information), and I don't think we should try to make it appear to
work in the backend in spite of that fact. Unfortunately, because of the way
that the ABI works, we need to generate code as if we supported interposition
whenever the linker might insert stubs for the purpose of supporting it.
Differential Revision: https://reviews.llvm.org/D27231
llvm-svn: 291003
2017-01-05 05:05:13 +08:00
|
|
|
; RUN: llc < %s -relocation-model=pic -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu | FileCheck %s
|
2018-12-05 04:14:57 +08:00
|
|
|
; RUN: llc < %s -relocation-model=pic -function-sections -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu | FileCheck %s -check-prefix=CHECK-FS
|
|
|
|
|
; RUN: llc < %s -relocation-model=pic -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu \
|
2017-08-22 01:35:32 +08:00
|
|
|
; RUN: -code-model=small -mcpu=pwr8 | FileCheck %s -check-prefix=SCM
|
[PowerPC] Fix logic dealing with nop after calls (and tail-call eligibility)
This change aims to unify and correct our logic for when we need to allow for
the possibility of the linker adding a TOC restoration instruction after a
call. This comes up in two contexts:
1. When determining tail-call eligibility. If we make a tail call (i.e.
directly branch to a function) then there is no place for the linker to add
a TOC restoration.
2. When determining when we need to add a nop instruction after a call.
Likewise, if there is a possibility that the linker might need to add a
TOC restoration after a call, then we need to put a nop after the call
(the bl instruction).
First problem: We were using similar, but different, logic to decide (1) and
(2). This is just wrong. Both the resideInSameModule function (used when
determining tail-call eligibility) and the isLocalCall function (used when
deciding if the post-call nop is needed) were supposed to be determining the
same underlying fact (i.e. might a TOC restoration be needed after the call).
The same logic should be used in both places.
Second problem: The logic in both places was wrong. We only know that two
functions will share the same TOC when both functions come from the same
section of the same object. Otherwise the linker might cause the functions to
use different TOC base addresses (unless the multi-TOC linker option is
disabled, in which case only shared-library boundaries are relevant). There are
a number of factors that can cause functions to be placed in different sections
or come from different objects (-ffunction-sections, explicitly-specified
section names, COMDAT, weak linkage, etc.). All of these need to be checked.
The existing logic only checked properties of the callee, but the properties of
the caller must also be checked (for example, calling from a function in a
COMDAT section means calling between sections).
There was a conceptual error in the resideInSameModule function in that it
allowed tail calls to functions with weak linkage and protected/hidden
visibility. While protected/hidden visibility does prevent the function
implementation from being replaced at runtime (via interposition), it does not
prevent the linker from using an alternate implementation at link time (i.e.
using some strong definition to replace the provided weak one during linking).
If this happens, then we're still potentially looking at a required TOC
restoration upon return.
Otherwise, in general, the post-call nop is needed wherever ELF interposition
needs to be supported. We don't currently support ELF interposition at the IR
level (see http://lists.llvm.org/pipermail/llvm-dev/2016-November/107625.html
for more information), and I don't think we should try to make it appear to
work in the backend in spite of that fact. Unfortunately, because of the way
that the ABI works, we need to generate code as if we supported interposition
whenever the linker might insert stubs for the purpose of supporting it.
Differential Revision: https://reviews.llvm.org/D27231
llvm-svn: 291003
2017-01-05 05:05:13 +08:00
|
|
|
|
|
|
|
|
%class.T = type { [2 x i8] }
|
|
|
|
|
|
|
|
|
|
define void @e_callee(%class.T* %this, i8* %c) { ret void }
|
|
|
|
|
define void @e_caller(%class.T* %this, i8* %c) {
|
|
|
|
|
call void @e_callee(%class.T* %this, i8* %c)
|
|
|
|
|
ret void
|
|
|
|
|
|
|
|
|
|
; CHECK-LABEL: e_caller:
|
|
|
|
|
; CHECK: bl e_callee
|
|
|
|
|
; CHECK-NEXT: nop
|
|
|
|
|
|
|
|
|
|
; CHECK-FS-LABEL: e_caller:
|
|
|
|
|
; CHECK-FS: bl e_callee
|
|
|
|
|
; CHECK-FS-NEXT: nop
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
define void @e_scallee(%class.T* %this, i8* %c) section "different" { ret void }
|
|
|
|
|
define void @e_scaller(%class.T* %this, i8* %c) {
|
|
|
|
|
call void @e_scallee(%class.T* %this, i8* %c)
|
|
|
|
|
ret void
|
|
|
|
|
|
|
|
|
|
; CHECK-LABEL: e_scaller:
|
|
|
|
|
; CHECK: bl e_scallee
|
|
|
|
|
; CHECK-NEXT: nop
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
define void @e_s2callee(%class.T* %this, i8* %c) { ret void }
|
|
|
|
|
define void @e_s2caller(%class.T* %this, i8* %c) section "different" {
|
|
|
|
|
call void @e_s2callee(%class.T* %this, i8* %c)
|
|
|
|
|
ret void
|
|
|
|
|
|
|
|
|
|
; CHECK-LABEL: e_s2caller:
|
|
|
|
|
; CHECK: bl e_s2callee
|
|
|
|
|
; CHECK-NEXT: nop
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
$cd1 = comdat any
|
|
|
|
|
$cd2 = comdat any
|
|
|
|
|
|
|
|
|
|
define void @e_ccallee(%class.T* %this, i8* %c) comdat($cd1) { ret void }
|
|
|
|
|
define void @e_ccaller(%class.T* %this, i8* %c) comdat($cd2) {
|
|
|
|
|
call void @e_ccallee(%class.T* %this, i8* %c)
|
|
|
|
|
ret void
|
|
|
|
|
|
|
|
|
|
; CHECK-LABEL: e_ccaller:
|
|
|
|
|
; CHECK: bl e_ccallee
|
|
|
|
|
; CHECK-NEXT: nop
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
$cd = comdat any
|
|
|
|
|
|
|
|
|
|
define void @e_c1callee(%class.T* %this, i8* %c) comdat($cd) { ret void }
|
|
|
|
|
define void @e_c1caller(%class.T* %this, i8* %c) comdat($cd) {
|
|
|
|
|
call void @e_c1callee(%class.T* %this, i8* %c)
|
|
|
|
|
ret void
|
|
|
|
|
|
|
|
|
|
; CHECK-LABEL: e_c1caller:
|
|
|
|
|
; CHECK: bl e_c1callee
|
|
|
|
|
; CHECK-NEXT: nop
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
define weak_odr hidden void @wo_hcallee(%class.T* %this, i8* %c) { ret void }
|
|
|
|
|
define void @wo_hcaller(%class.T* %this, i8* %c) {
|
|
|
|
|
call void @wo_hcallee(%class.T* %this, i8* %c)
|
|
|
|
|
ret void
|
|
|
|
|
|
|
|
|
|
; CHECK-LABEL: wo_hcaller:
|
|
|
|
|
; CHECK: bl wo_hcallee
|
2017-08-22 01:35:32 +08:00
|
|
|
; CHECK-NOT: nop
|
|
|
|
|
|
|
|
|
|
; SCM-LABEL: wo_hcaller:
|
|
|
|
|
; SCM: bl wo_hcallee
|
|
|
|
|
; SCM-NEXT: nop
|
[PowerPC] Fix logic dealing with nop after calls (and tail-call eligibility)
This change aims to unify and correct our logic for when we need to allow for
the possibility of the linker adding a TOC restoration instruction after a
call. This comes up in two contexts:
1. When determining tail-call eligibility. If we make a tail call (i.e.
directly branch to a function) then there is no place for the linker to add
a TOC restoration.
2. When determining when we need to add a nop instruction after a call.
Likewise, if there is a possibility that the linker might need to add a
TOC restoration after a call, then we need to put a nop after the call
(the bl instruction).
First problem: We were using similar, but different, logic to decide (1) and
(2). This is just wrong. Both the resideInSameModule function (used when
determining tail-call eligibility) and the isLocalCall function (used when
deciding if the post-call nop is needed) were supposed to be determining the
same underlying fact (i.e. might a TOC restoration be needed after the call).
The same logic should be used in both places.
Second problem: The logic in both places was wrong. We only know that two
functions will share the same TOC when both functions come from the same
section of the same object. Otherwise the linker might cause the functions to
use different TOC base addresses (unless the multi-TOC linker option is
disabled, in which case only shared-library boundaries are relevant). There are
a number of factors that can cause functions to be placed in different sections
or come from different objects (-ffunction-sections, explicitly-specified
section names, COMDAT, weak linkage, etc.). All of these need to be checked.
The existing logic only checked properties of the callee, but the properties of
the caller must also be checked (for example, calling from a function in a
COMDAT section means calling between sections).
There was a conceptual error in the resideInSameModule function in that it
allowed tail calls to functions with weak linkage and protected/hidden
visibility. While protected/hidden visibility does prevent the function
implementation from being replaced at runtime (via interposition), it does not
prevent the linker from using an alternate implementation at link time (i.e.
using some strong definition to replace the provided weak one during linking).
If this happens, then we're still potentially looking at a required TOC
restoration upon return.
Otherwise, in general, the post-call nop is needed wherever ELF interposition
needs to be supported. We don't currently support ELF interposition at the IR
level (see http://lists.llvm.org/pipermail/llvm-dev/2016-November/107625.html
for more information), and I don't think we should try to make it appear to
work in the backend in spite of that fact. Unfortunately, because of the way
that the ABI works, we need to generate code as if we supported interposition
whenever the linker might insert stubs for the purpose of supporting it.
Differential Revision: https://reviews.llvm.org/D27231
llvm-svn: 291003
2017-01-05 05:05:13 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
define weak_odr protected void @wo_pcallee(%class.T* %this, i8* %c) { ret void }
|
|
|
|
|
define void @wo_pcaller(%class.T* %this, i8* %c) {
|
|
|
|
|
call void @wo_pcallee(%class.T* %this, i8* %c)
|
|
|
|
|
ret void
|
|
|
|
|
|
|
|
|
|
; CHECK-LABEL: wo_pcaller:
|
|
|
|
|
; CHECK: bl wo_pcallee
|
2017-08-22 01:35:32 +08:00
|
|
|
; CHECK-NOT: nop
|
|
|
|
|
|
|
|
|
|
; SCM-LABEL: wo_pcaller:
|
|
|
|
|
; SCM: bl wo_pcallee
|
|
|
|
|
; SCM-NEXT: nop
|
[PowerPC] Fix logic dealing with nop after calls (and tail-call eligibility)
This change aims to unify and correct our logic for when we need to allow for
the possibility of the linker adding a TOC restoration instruction after a
call. This comes up in two contexts:
1. When determining tail-call eligibility. If we make a tail call (i.e.
directly branch to a function) then there is no place for the linker to add
a TOC restoration.
2. When determining when we need to add a nop instruction after a call.
Likewise, if there is a possibility that the linker might need to add a
TOC restoration after a call, then we need to put a nop after the call
(the bl instruction).
First problem: We were using similar, but different, logic to decide (1) and
(2). This is just wrong. Both the resideInSameModule function (used when
determining tail-call eligibility) and the isLocalCall function (used when
deciding if the post-call nop is needed) were supposed to be determining the
same underlying fact (i.e. might a TOC restoration be needed after the call).
The same logic should be used in both places.
Second problem: The logic in both places was wrong. We only know that two
functions will share the same TOC when both functions come from the same
section of the same object. Otherwise the linker might cause the functions to
use different TOC base addresses (unless the multi-TOC linker option is
disabled, in which case only shared-library boundaries are relevant). There are
a number of factors that can cause functions to be placed in different sections
or come from different objects (-ffunction-sections, explicitly-specified
section names, COMDAT, weak linkage, etc.). All of these need to be checked.
The existing logic only checked properties of the callee, but the properties of
the caller must also be checked (for example, calling from a function in a
COMDAT section means calling between sections).
There was a conceptual error in the resideInSameModule function in that it
allowed tail calls to functions with weak linkage and protected/hidden
visibility. While protected/hidden visibility does prevent the function
implementation from being replaced at runtime (via interposition), it does not
prevent the linker from using an alternate implementation at link time (i.e.
using some strong definition to replace the provided weak one during linking).
If this happens, then we're still potentially looking at a required TOC
restoration upon return.
Otherwise, in general, the post-call nop is needed wherever ELF interposition
needs to be supported. We don't currently support ELF interposition at the IR
level (see http://lists.llvm.org/pipermail/llvm-dev/2016-November/107625.html
for more information), and I don't think we should try to make it appear to
work in the backend in spite of that fact. Unfortunately, because of the way
that the ABI works, we need to generate code as if we supported interposition
whenever the linker might insert stubs for the purpose of supporting it.
Differential Revision: https://reviews.llvm.org/D27231
llvm-svn: 291003
2017-01-05 05:05:13 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
define weak_odr void @wo_callee(%class.T* %this, i8* %c) { ret void }
|
|
|
|
|
define void @wo_caller(%class.T* %this, i8* %c) {
|
|
|
|
|
call void @wo_callee(%class.T* %this, i8* %c)
|
|
|
|
|
ret void
|
|
|
|
|
|
|
|
|
|
; CHECK-LABEL: wo_caller:
|
|
|
|
|
; CHECK: bl wo_callee
|
|
|
|
|
; CHECK-NEXT: nop
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
define weak protected void @w_pcallee(i8* %ptr) { ret void }
|
|
|
|
|
define void @w_pcaller(i8* %ptr) {
|
|
|
|
|
call void @w_pcallee(i8* %ptr)
|
|
|
|
|
ret void
|
|
|
|
|
|
|
|
|
|
; CHECK-LABEL: w_pcaller:
|
|
|
|
|
; CHECK: bl w_pcallee
|
2017-08-22 01:35:32 +08:00
|
|
|
; CHECK-NOT: nop
|
|
|
|
|
|
|
|
|
|
; SCM-LABEL: w_pcaller:
|
|
|
|
|
; SCM: bl w_pcallee
|
|
|
|
|
; SCM-NEXT: nop
|
[PowerPC] Fix logic dealing with nop after calls (and tail-call eligibility)
This change aims to unify and correct our logic for when we need to allow for
the possibility of the linker adding a TOC restoration instruction after a
call. This comes up in two contexts:
1. When determining tail-call eligibility. If we make a tail call (i.e.
directly branch to a function) then there is no place for the linker to add
a TOC restoration.
2. When determining when we need to add a nop instruction after a call.
Likewise, if there is a possibility that the linker might need to add a
TOC restoration after a call, then we need to put a nop after the call
(the bl instruction).
First problem: We were using similar, but different, logic to decide (1) and
(2). This is just wrong. Both the resideInSameModule function (used when
determining tail-call eligibility) and the isLocalCall function (used when
deciding if the post-call nop is needed) were supposed to be determining the
same underlying fact (i.e. might a TOC restoration be needed after the call).
The same logic should be used in both places.
Second problem: The logic in both places was wrong. We only know that two
functions will share the same TOC when both functions come from the same
section of the same object. Otherwise the linker might cause the functions to
use different TOC base addresses (unless the multi-TOC linker option is
disabled, in which case only shared-library boundaries are relevant). There are
a number of factors that can cause functions to be placed in different sections
or come from different objects (-ffunction-sections, explicitly-specified
section names, COMDAT, weak linkage, etc.). All of these need to be checked.
The existing logic only checked properties of the callee, but the properties of
the caller must also be checked (for example, calling from a function in a
COMDAT section means calling between sections).
There was a conceptual error in the resideInSameModule function in that it
allowed tail calls to functions with weak linkage and protected/hidden
visibility. While protected/hidden visibility does prevent the function
implementation from being replaced at runtime (via interposition), it does not
prevent the linker from using an alternate implementation at link time (i.e.
using some strong definition to replace the provided weak one during linking).
If this happens, then we're still potentially looking at a required TOC
restoration upon return.
Otherwise, in general, the post-call nop is needed wherever ELF interposition
needs to be supported. We don't currently support ELF interposition at the IR
level (see http://lists.llvm.org/pipermail/llvm-dev/2016-November/107625.html
for more information), and I don't think we should try to make it appear to
work in the backend in spite of that fact. Unfortunately, because of the way
that the ABI works, we need to generate code as if we supported interposition
whenever the linker might insert stubs for the purpose of supporting it.
Differential Revision: https://reviews.llvm.org/D27231
llvm-svn: 291003
2017-01-05 05:05:13 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
define weak hidden void @w_hcallee(i8* %ptr) { ret void }
|
|
|
|
|
define void @w_hcaller(i8* %ptr) {
|
|
|
|
|
call void @w_hcallee(i8* %ptr)
|
|
|
|
|
ret void
|
|
|
|
|
|
|
|
|
|
; CHECK-LABEL: w_hcaller:
|
|
|
|
|
; CHECK: bl w_hcallee
|
2017-08-22 01:35:32 +08:00
|
|
|
; CHECK-NOT: nop
|
|
|
|
|
|
|
|
|
|
; SCM-LABEL: w_hcaller:
|
|
|
|
|
; SCM: bl w_hcallee
|
|
|
|
|
; SCM-NEXT: nop
|
[PowerPC] Fix logic dealing with nop after calls (and tail-call eligibility)
This change aims to unify and correct our logic for when we need to allow for
the possibility of the linker adding a TOC restoration instruction after a
call. This comes up in two contexts:
1. When determining tail-call eligibility. If we make a tail call (i.e.
directly branch to a function) then there is no place for the linker to add
a TOC restoration.
2. When determining when we need to add a nop instruction after a call.
Likewise, if there is a possibility that the linker might need to add a
TOC restoration after a call, then we need to put a nop after the call
(the bl instruction).
First problem: We were using similar, but different, logic to decide (1) and
(2). This is just wrong. Both the resideInSameModule function (used when
determining tail-call eligibility) and the isLocalCall function (used when
deciding if the post-call nop is needed) were supposed to be determining the
same underlying fact (i.e. might a TOC restoration be needed after the call).
The same logic should be used in both places.
Second problem: The logic in both places was wrong. We only know that two
functions will share the same TOC when both functions come from the same
section of the same object. Otherwise the linker might cause the functions to
use different TOC base addresses (unless the multi-TOC linker option is
disabled, in which case only shared-library boundaries are relevant). There are
a number of factors that can cause functions to be placed in different sections
or come from different objects (-ffunction-sections, explicitly-specified
section names, COMDAT, weak linkage, etc.). All of these need to be checked.
The existing logic only checked properties of the callee, but the properties of
the caller must also be checked (for example, calling from a function in a
COMDAT section means calling between sections).
There was a conceptual error in the resideInSameModule function in that it
allowed tail calls to functions with weak linkage and protected/hidden
visibility. While protected/hidden visibility does prevent the function
implementation from being replaced at runtime (via interposition), it does not
prevent the linker from using an alternate implementation at link time (i.e.
using some strong definition to replace the provided weak one during linking).
If this happens, then we're still potentially looking at a required TOC
restoration upon return.
Otherwise, in general, the post-call nop is needed wherever ELF interposition
needs to be supported. We don't currently support ELF interposition at the IR
level (see http://lists.llvm.org/pipermail/llvm-dev/2016-November/107625.html
for more information), and I don't think we should try to make it appear to
work in the backend in spite of that fact. Unfortunately, because of the way
that the ABI works, we need to generate code as if we supported interposition
whenever the linker might insert stubs for the purpose of supporting it.
Differential Revision: https://reviews.llvm.org/D27231
llvm-svn: 291003
2017-01-05 05:05:13 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
define weak void @w_callee(i8* %ptr) { ret void }
|
|
|
|
|
define void @w_caller(i8* %ptr) {
|
|
|
|
|
call void @w_callee(i8* %ptr)
|
|
|
|
|
ret void
|
|
|
|
|
|
|
|
|
|
; CHECK-LABEL: w_caller:
|
|
|
|
|
; CHECK: bl w_callee
|
|
|
|
|
; CHECK-NEXT: nop
|
|
|
|
|
}
|
|
|
|
|
|