The Float32RoundUp operator rounds float32 numbers towards infinity.
The operator is currently implemented on x64, ia32, arm, and arm64.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1474963002
Cr-Commit-Position: refs/heads/master@{#32262}
This change replaces the bitwise masking of uses by storing the most general truncation for all uses.
Review URL: https://codereview.chromium.org/1464763003
Cr-Commit-Position: refs/heads/master@{#32248}
Adds code and tests to support CreateClosure bytecode when building
graphs.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1458603012
Cr-Commit-Position: refs/heads/master@{#32224}
Adds support for the New, CallRuntime and CallJSRuntime bytecodes in
BytecodeGraphBuilder. Also adds BuildLoadObjectField,
BuildLoadGlobalObject and BuildLoadNativeContextField helpers.
Landed on behalf of rmcilroy.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1456483002
Cr-Commit-Position: refs/heads/master@{#32136}
The TruncateFloat64ToUint64 operator converts a float64 to an uint64 using
round-to-zero rounding mode (truncate). If the input value is outside uint64
range, then the result depends on the architecture. I provide an implementation for x64 and arm64.
@v8-ppc-ports and @v8-mips-ports, can you do the implementations for ppc64 and mips64?
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1457373002
Cr-Commit-Position: refs/heads/master@{#32127}
The ChangeFloat64ToInt64 operator changes the representation of a
float64 input value to int64 if the input value can be represented
exactly on int64. Otherwise the result is currently undefined.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1455983002
Cr-Commit-Position: refs/heads/master@{#32102}
If the input type does not help us, we are conservative and truncate (rather than guessing signed).
Review URL: https://codereview.chromium.org/1455103002
Cr-Commit-Position: refs/heads/master@{#32075}
Adds support for the LdaGlobal and StaGlobal bytecodes to the
BytecodeGraphBuilder. Also fixes a bug in the context node's parameter
index and start node inputs.
Landed on behalf of rmcilroy.
TBR=bmeuer@chromium.org,mythria@chromium.org
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1449373002
Cr-Commit-Position: refs/heads/master@{#32049}
Adds support for visiting the Call bytecode to the bytecode graph builder.
This change also adds the call type feedback slot to the Call bytecode.
This is not currently used by the interpreter, but is used by the
graph builder.
Also adds a CallWide varient of the Call bytecode, and adds the kCount16
operand type.
Landed on behalf of rmcilroy.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1456453002
Cr-Commit-Position: refs/heads/master@{#32033}
Adds implementation and tests for following operators in bytecode graph builder:
-VisitLoadICSloppy
-VisitLoadICStrict
-VisitLoadICSloppyWide
-VisitLoadICStrictWide
The current implementation introduces empty frame states for frame state inputs expected by these operations.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1419373007
Cr-Commit-Position: refs/heads/master@{#32026}
The TiesEven rounding mode rounds float64 numbers to the nearest
integer. If there are two nearest integers, then the number is rounded
to the even one. This is the default rounding mode according to
IEEE~754.
I implemented the operator on ia32, x64, arm, arm64, mips, and mips64.
I think there is a bug in the current implementation of the ppc
simulator, which kept me from implementing the operator on ppc.
According to my understanding of the ppc instruction manual, the FRIN
instruction provides the right behavior for Float64RoundTiesEven. In the
simulator, however, FRIN provides a different semantics. If there are
two nearest integers, then the simulator returns the one which is
further away form 0.
Review URL: https://codereview.chromium.org/1440293002
Cr-Commit-Position: refs/heads/master@{#32005}
This is necessary to allow more optimizations to take place between
the representation inference and change lowering. Perhaps we want
to rename SimplifiedLowering -> RepresentationInference and
ChangeLowering -> SimplifiedLowering.
Review URL: https://codereview.chromium.org/1439473003
Cr-Commit-Position: refs/heads/master@{#31976}
The least significant bit of the input value may affect the result of
the conversion through rounding. We OR the least significant with the
second least significant bit to preserve it over the SHR instruction.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1435203003
Cr-Commit-Position: refs/heads/master@{#31969}
Popcnt is implemented as an optional operator, which is only implementd by x64
at the moment.
Review URL: https://codereview.chromium.org/1424173006
Cr-Commit-Position: refs/heads/master@{#31928}
This patch extends the typed lowering with a specialized version of 'instanceof' that is used if the "class", i.e. the constructor function, is a known constant.
Unittests check that replacement occurs as intended. Functional correctness is ensured by extensive unit tests covering instanceof already in the testsuite.
TESTS=unittests/JSTypedLoweringTest.{JSInstanceOfSpecializationWithSmiCheck,JSInstanceOfSpecializationWithoutSmiCheck,JSInstanceOfNoSpecialization}
Review URL: https://codereview.chromium.org/1407413014
Cr-Commit-Position: refs/heads/master@{#31916}
I improved the tests for Word32Clz, Word32Ctz, and Word32Popcnt, and ported
some tests to the BufferedRawMachineAssemblerTester.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1437493002
Cr-Commit-Position: refs/heads/master@{#31896}
This change does not change how the BufferedRawMachineAssemblerTester is
used in tests, but it makes its construction in other constructors (e.g.
in the WasmRunner) cleaner.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1414203009
Cr-Commit-Position: refs/heads/master@{#31850}
The %_CallFunction doesn't implement the call sequence properly, it
doesn't do the receiver wrapping, nor does it check for
classConstructor. Also the eager deoptimization for %_CallFunction was
seriously b0rked (we must have been lucky with TurboFan so far).
R=yangguo@chromium.org
BUG=v8:4413
LOG=n
Review URL: https://codereview.chromium.org/1419813010
Cr-Commit-Position: refs/heads/master@{#31821}
TurboFan didn't fully support the relevant ES6 type conversion
intrinsics like %_ToNumber, %_ToLength, %_ToName, %_ToString and
%_ToInteger until now, we always went to the runtime instead. These
intrinsics are now well supported in TurboFan, and we are even able to
generate quite decent code in some cases.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1428243003
Cr-Commit-Position: refs/heads/master@{#31820}
The CL https://codereview.chromium.org/1409013004 added / changed some test cases.
Some new test cases use CheckFloatEq(...) and CheckDoubleEq(...) function for result
check. When GCC compiling the CheckFloatEq() and CheckDoubleEq() function, those inlined
functions has different behavior comparing with GCC ia32 build and x87 build. The major
difference is sse float register still has single precision rounding semantic. While X87
register has no such rounding precsion semantic when directly use register value. The V8
turbofan JITTed has exactly same result in both X87 and IA32 port.
So we add the following sentence to do type case to keep the same precision.
float expect = *i * *j; // *i + *j, etc.
For test case "RunFloat64MulAndFloat64Add1 / RunFloat64MulAndFloat64Add2 / RunFloat64MulAndFloat64Sub1
/ RunFloat64MulAndFloat64Sub2", the expected result calcaulated by GCC has difference precsion
when comparing with V8 turbofan result for X87 platform. (Turbofan X87 result is the same as
IA32 GCC and IA32 Turbofan). So we have to disable those four cases for X87 port.
BUG=
Review URL: https://codereview.chromium.org/1430943002
Cr-Commit-Position: refs/heads/master@{#31808}
The BufferedRawMachineAssemblerTester takes care of storing and loading
parameters to and from memory for these test cases. By using the
BufferedRawMachineAssemblerTester the test cases become more readible.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1409013004
Cr-Commit-Position: refs/heads/master@{#31718}
This utility makes it possible to test TF graphs that accept parameters of any machine type (even int64 and float64), which are previously problematic due to the complexity of C calling conventions.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1423133005
Cr-Commit-Position: refs/heads/master@{#31698}
This moves all cctest files for the compiler to live in the same
namespace as the components they are testing. Hence we can avoid the
forbidden using directives pulling in entire namespaces.
From the Google C++ style guide: "You may not use a using-directive to
make all names from a namespace available". This would be covered by
presubmit linter checks if build/namespaces were not blacklisted.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1424943004
Cr-Commit-Position: refs/heads/master@{#31671}
