Fix crash when inlining intrinsics with specialized HIR

During the inliner phase if we recognize an intrinsic, we insert it.
This is problematic since there are some intrinsics which we only
expect during the instruction builder phase. This CL skips
inlining those intrinsics.

Potentially, we could generate the graphs for those intrinsics and
inline it, but it needs refactoring of inliner.cc.

Bug: 319045458
Fixes: 319045458
Test: art/test/testrunner/testrunner.py --host --64 --optimizing -b
Test: Locally compiling the app in the bug
Change-Id: Ied3ec87e5655cec3bdfd978eb5c7411ddb102360

1 files changed, 11 insertions, 0 deletions

diff --git a/compiler/optimizing/intrinsics.h b/compiler/optimizing/intrinsics.h
index d14d264204..0a431b8aa8 100644
--- a/compiler/optimizing/intrinsics.h
+++ b/compiler/optimizing/intrinsics.h
@@ -177,6 +177,17 @@ static inline bool IsIntrinsicWithSpecializedHir(Intrinsics intrinsic) {
   }
 }
 
+static inline bool IsValidIntrinsicAfterBuilder(Intrinsics intrinsic) {
+  return !IsIntrinsicWithSpecializedHir(intrinsic) ||
+         // FIXME: The inliner can currently create graphs with any of the intrinsics with HIR.
+         // However, we are able to compensate for `StringCharAt` and `StringLength` in the
+         // `HInstructionSimplifier`, so we're allowing these two intrinsics for now, preserving
+         // the old behavior. Besides fixing the bug, we should also clean up the simplifier
+         // and remove `SimplifyStringCharAt` and `SimplifyStringLength`. Bug: 319045458
+         intrinsic == Intrinsics::kStringCharAt ||
+         intrinsic == Intrinsics::kStringLength;
+}
+
 #define GENERIC_OPTIMIZATION(name, bit)                \
 public:                                                \
 void Set##name() { SetBit(k##name); }                  \