summaryrefslogtreecommitdiff
path: root/include/clang
diff options
context:
space:
mode:
authorPete Cooper <peter_cooper@apple.com>2016-03-21 20:50:03 +0000
committerPete Cooper <peter_cooper@apple.com>2016-03-21 20:50:03 +0000
commit2a988fcf43affedeadac7714fbce007eec732b2b (patch)
treef4ebbd93b3353498bf2b4a4c5a6289a03e64026a /include/clang
parent2ce38073fd10b6ec77c8ceb594a93ac238e7ee48 (diff)
downloadclang-2a988fcf43affedeadac7714fbce007eec732b2b.tar.gz
Revert "Convert some ObjC msgSends to runtime calls."
This reverts commit r263607. This change caused more objc_retain/objc_release calls in the IR but those are then incorrectly optimized by the ARC optimizer. Work is going to have to be done to ensure the ARC optimizer doesn't optimize user written RR, but that should land before this change. This change will also need to be updated to take account for any changes required to ensure that user written calls to RR are distinct from those inserted by ARC. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@263984 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'include/clang')
-rw-r--r--include/clang/Basic/ObjCRuntime.h73
-rw-r--r--include/clang/Driver/Options.td4
-rw-r--r--include/clang/Frontend/CodeGenOptions.def2
3 files changed, 0 insertions, 79 deletions
diff --git a/include/clang/Basic/ObjCRuntime.h b/include/clang/Basic/ObjCRuntime.h
index 675e6649cd..6975b6c9bb 100644
--- a/include/clang/Basic/ObjCRuntime.h
+++ b/include/clang/Basic/ObjCRuntime.h
@@ -171,79 +171,6 @@ public:
llvm_unreachable("bad kind");
}
- /// Does this runtime provide ARC entrypoints that are likely to be faster
- /// than an ordinary message send of the appropriate selector?
- ///
- /// The ARC entrypoints are guaranteed to be equivalent to just sending the
- /// corresponding message. If the entrypoint is implemented naively as just a
- /// message send, using it is a trade-off: it sacrifices a few cycles of
- /// overhead to save a small amount of code. However, it's possible for
- /// runtimes to detect and special-case classes that use "standard"
- /// retain/release behavior; if that's dynamically a large proportion of all
- /// retained objects, using the entrypoint will also be faster than using a
- /// message send.
- ///
- /// When this method returns true, Clang will turn non-super message sends of
- /// certain selectors into calls to the correspond entrypoint:
- /// retain => objc_retain
- /// release => objc_release
- bool shouldUseARCFunctionsForRetainRelease() const {
- switch (getKind()) {
- case FragileMacOSX:
- return false;
- case MacOSX:
- return getVersion() >= VersionTuple(10, 10);
- case iOS:
- return getVersion() >= VersionTuple(8);
- case WatchOS:
- return true;
-
- case GCC:
- return false;
- case GNUstep:
- return false;
- case ObjFW:
- return false;
- }
- llvm_unreachable("bad kind");
- }
-
- /// Does this runtime provide entrypoints that are likely to be faster
- /// than an ordinary message send of the "alloc" selector?
- ///
- /// The "alloc" entrypoint is guaranteed to be equivalent to just sending the
- /// corresponding message. If the entrypoint is implemented naively as just a
- /// message send, using it is a trade-off: it sacrifices a few cycles of
- /// overhead to save a small amount of code. However, it's possible for
- /// runtimes to detect and special-case classes that use "standard"
- /// alloc behavior; if that's dynamically a large proportion of all
- /// objects, using the entrypoint will also be faster than using a message
- /// send.
- ///
- /// When this method returns true, Clang will turn non-super message sends of
- /// certain selectors into calls to the correspond entrypoint:
- /// alloc => objc_alloc
- bool shouldUseRuntimeFunctionsForAlloc() const {
- switch (getKind()) {
- case FragileMacOSX:
- return false;
- case MacOSX:
- return getVersion() >= VersionTuple(10, 10);
- case iOS:
- return getVersion() >= VersionTuple(8);
- case WatchOS:
- return true;
-
- case GCC:
- return false;
- case GNUstep:
- return false;
- case ObjFW:
- return false;
- }
- llvm_unreachable("bad kind");
- }
-
/// \brief Does this runtime supports optimized setter entrypoints?
bool hasOptimizedSetter() const {
switch (getKind()) {
diff --git a/include/clang/Driver/Options.td b/include/clang/Driver/Options.td
index 91d6b075f9..9f0ab25698 100644
--- a/include/clang/Driver/Options.td
+++ b/include/clang/Driver/Options.td
@@ -933,10 +933,6 @@ def fno_zero_initialized_in_bss : Flag<["-"], "fno-zero-initialized-in-bss">, Gr
def fobjc_arc : Flag<["-"], "fobjc-arc">, Group<f_Group>, Flags<[CC1Option]>,
HelpText<"Synthesize retain and release calls for Objective-C pointers">;
def fno_objc_arc : Flag<["-"], "fno-objc-arc">, Group<f_Group>;
-def fobjc_convert_messages_to_runtime_calls :
- Flag<["-"], "fobjc-convert-messages-to-runtime-calls">, Group<f_Group>;
-def fno_objc_convert_messages_to_runtime_calls :
- Flag<["-"], "fno-objc-convert-messages-to-runtime-calls">, Group<f_Group>, Flags<[CC1Option]>;
def fobjc_arc_exceptions : Flag<["-"], "fobjc-arc-exceptions">, Group<f_Group>, Flags<[CC1Option]>,
HelpText<"Use EH-safe code when synthesizing retains and releases in -fobjc-arc">;
def fno_objc_arc_exceptions : Flag<["-"], "fno-objc-arc-exceptions">, Group<f_Group>;
diff --git a/include/clang/Frontend/CodeGenOptions.def b/include/clang/Frontend/CodeGenOptions.def
index 7d836bdde6..cd5b50c528 100644
--- a/include/clang/Frontend/CodeGenOptions.def
+++ b/include/clang/Frontend/CodeGenOptions.def
@@ -99,8 +99,6 @@ CODEGENOPT(NoNaNsFPMath , 1, 0) ///< Assume FP arguments, results not NaN.
CODEGENOPT(NoZeroInitializedInBSS , 1, 0) ///< -fno-zero-initialized-in-bss.
/// \brief Method of Objective-C dispatch to use.
ENUM_CODEGENOPT(ObjCDispatchMethod, ObjCDispatchMethodKind, 2, Legacy)
-/// Replace certain message sends with calls to ObjC runtime entrypoints
-CODEGENOPT(ObjCConvertMessagesToRuntimeCalls , 1, 1)
CODEGENOPT(OmitLeafFramePointer , 1, 0) ///< Set when -momit-leaf-frame-pointer is
///< enabled.
VALUE_CODEGENOPT(OptimizationLevel, 2, 0) ///< The -O[0-3] option specified.