[MERGE #1396 @ThomsonTan] Check fast path of Math.pow in interpreter to make the result consistent with JIT code

Merge pull request #1396 from ThomsonTan:FixMathPowInconsistency

Interpreter always go to slow path of Math.pow because the perf win is not substantial in interpreter, and but could give more accurate float point result. This leads to result inconsistency between JIT code and interpreter.  This fix checks fast path in interpreter to make the result consistent.

Author: ThomsonTan

lib/Runtime/Library/JavascriptNumber.cpp

@@ -283,6 +283,7 @@ namespace Js
         // For AMD64/ARM calling convention already uses SSE2/VFP registers so we don't have to use assembler.
         // We can't just use "if (0 == y)" because NaN compares
         // equal to 0 according to our compilers.
+        int32 intY;
         if (0 == NumberUtilities::LuLoDbl(y) && 0 == (NumberUtilities::LuHiDbl(y) & 0x7FFFFFFF))
         {
             // pow(x, 0) = 1 even if x is NaN.
@@ -293,6 +294,11 @@ namespace Js
             // pow([+/-] 1, Infinity) = NaN according to javascript, but not for CRT pow.
             return JavascriptNumber::NaN;
         }
+        else if (TryGetInt32Value(y, &intY))
+        {
+            // check fast path
+            return DirectPowDoubleInt(x, intY);
+        }
 
         return ::pow(x, y);
     }