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

1 files changed, 0 insertions, 73 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()) {