From: Brian Sullivan <briansul@microsoft.com>
Date: Mon, 30 Apr 2018 23:03:11 +0000 (-0700)
Subject: ARM64 like ARM32 also needs a much larger instruction group size
X-Git-Tag: accepted/tizen/unified/20190422.045933~2220^2
X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=94aee98c2acf2a59f52684f7062172d21e0c582c;p=platform%2Fupstream%2Fcoreclr.git

ARM64 like ARM32 also needs a much larger instruction group size
because the prolog can be quite large.
---

diff --git a/src/jit/emit.h b/src/jit/emit.h
index 0d27948..337ab1b 100644
--- a/src/jit/emit.h
+++ b/src/jit/emit.h
@@ -1741,18 +1741,18 @@ private:
 /*      The logic that creates and keeps track of instruction groups    */
 /************************************************************************/
 
-#ifdef _TARGET_ARM_
+#ifdef _TARGET_ARMARCH_
 // The only place where this limited instruction group size is a problem is
 // in the prolog, where we only support a single instruction group. We should really fix that.
-// ARM can require a bigger prolog instruction group. One scenario is where a
-// function uses all the incoming integer and single-precision floating-point arguments,
+// ARM32 and ARM64 both can require a bigger prolog instruction group. One scenario is where
+// a function uses all the incoming integer and single-precision floating-point arguments,
 // and must store them all to the frame on entry. If the frame is very large, we generate
 // ugly code like "movw r10, 0x488; add r10, sp; vstr s0, [r10]" for each store, which
 // eats up our insGroup buffer.
 #define SC_IG_BUFFER_SIZE (100 * sizeof(instrDesc) + 14 * TINY_IDSC_SIZE)
-#else // !_TARGET_ARM_
+#else // !_TARGET_ARMARCH_
 #define SC_IG_BUFFER_SIZE (50 * sizeof(instrDesc) + 14 * TINY_IDSC_SIZE)
-#endif // !_TARGET_ARM_
+#endif // !_TARGET_ARMARCH_
 
     size_t emitIGbuffSize;