The previous register allocation allowed invalid register aliasing in
cases where in the TF graph the node was used for multiple inputs of the
Word32PairShl node.
Additionally I renamed PairLsl to LslPair in the code generation for
consistency.
R=titzer@chromium.org, v8-arm-ports@googlegroups.com
Review URL: https://codereview.chromium.org/1776393004
Cr-Commit-Position: refs/heads/master@{#34755}
Int64Add is lowered to a new turbofan operator, Int32AddPair. The new
operator takes 4 inputs an generates 2 outputs. The inputs are the low
word of the left input, high word of the left input, the low word of the
right input, and high word of the right input. The ouputs are the low
and high word of the result of the addition.
R=titzer@chromium.org, v8-arm-ports@googlegroups.com
Review URL: https://codereview.chromium.org/1778493004
Cr-Commit-Position: refs/heads/master@{#34747}
Instead of using CheckFloatEq and CheckDoubleEq directly, I introduced
a macro which first stores the expected result in a volatile variable.
Here are some comments of previous CLs:
The reason is same as the CL #31808 (issue 1430943002, X87: Change the test case for X87 float operations), please refer: https://codereview.chromium.org/1430943002/.
Here is the key comments from CL #31808
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 cast to keep the same precision for RunCallInt64ToFloat32/RunCallInt64ToFloat64. Such as: volatile double expect = static_cast<float>(*i).
R=titzer@chromium.org, weiliang.lin@intel.com
Review URL: https://codereview.chromium.org/1773513002
Cr-Commit-Position: refs/heads/master@{#34534}
On 32-bit systems FXXXConvertI64 instructions are compiled to calls to
C functions. The TF node for the function call is already generated in
the wasm compiler, the lowering of the I64 parameter is done in the
Int64Lowering.
R=titzer@chromium.org, yangguo@chromium.org
Review URL: https://codereview.chromium.org/1738623003
Cr-Commit-Position: refs/heads/master@{#34487}
The CL #33796 (https://codereview.chromium.org/1628133002) added the RunRoundUint32ToFloat32 test case and X87 failed at it.
The reason is same as the CL #33630 (Issue 1649323002: X87: Change the test case for X87 RunRoundInt32ToFloat32), please refer: https://codereview.chromium.org/1649323002.
Here is the key comments from CL #33630:
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.
For CHECK_EQ(a, b) function, if a and b are doubles, it will has similar behaviors like CheckFloatEq(...) and CheckDoubleEq(...) function when compiled by GCC and causes the test case
fail.
So we add the following sentence to do type case to keep the same precision for RunRoundUint32ToFloat32. Such as: volatile double expect = static_cast<float>(*i).
BUG=
Review URL: https://codereview.chromium.org/1714413002
Cr-Commit-Position: refs/heads/master@{#34202}
This functionality is useful for stubs that need to walk the stack. The new
machine operator, LoadParentFramePointer dosn't force the currently compiling
method to have a frame in contrast to LoadFramePointer. Instead, it adapts
accordingly when frame elision is possible, making efficient stack walks
possible without incurring a performance penalty for small stubs that can
benefit from frame elision.
R=bmeurer@chromium.org
LOG=N
Review URL: https://codereview.chromium.org/1695313002
Cr-Commit-Position: refs/heads/master@{#34014}
If the architecture does not provide rounding instructions, then C
implementations of these rounding instructions are called. The C
implementations from math.h are used, function pointers are registered
as external references so that they can be call from the simulator.
R=titzer@chromium.org
BUG=575379
LOG=Y
Review URL: https://codereview.chromium.org/1661463002
Cr-Commit-Position: refs/heads/master@{#33677}
The CL #33347 (https://codereview.chromium.org/1589363002) added the RunRoundInt32ToFloat32 test case and X87 failed at it.
The reason is same as the CL #31808 (issue 1430943002, X87: Change the test case for X87 float operations), please refer: https://codereview.chromium.org/1430943002/.
Here is the key comments from CL #31808
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.
For CHECK_EQ(a, b) function, if a and b are doubles, it will has similar behaviors like CheckFloatEq(...) and CheckDoubleEq(...) function when compiled by GCC and causes the test case
fail.
So we add the following sentence to do type case to keep the same precision for RunRoundInt32ToFloat32. Such as: volatile double expect = static_cast<float>(*i).
BUG=
Review URL: https://codereview.chromium.org/1649323002
Cr-Commit-Position: refs/heads/master@{#33630}
Reason for revert:
problems on Mac64
Original issue's description:
> [turbofan] Add the StackSlot operator to turbofan.
>
> The StackSlot operator allows to allocate a spill slot on the stack. We
> are going to use this operator to pass floats through pointers to c
> functions, which we need for floating point rounding in the case where
> the architecture does not provide rounding instructions.
>
> R=titzer@chromium.org, v8-arm-ports@googlegroups.com, v8-ppc-ports@googlegroups.com, v8-mips-ports@googlegroups.com
>
> Committed: https://crrev.com/7a693437787090d62d937b862e29521debcc5223
> Cr-Commit-Position: refs/heads/master@{#33600}
TBR=titzer@chromium.org,v8-arm-ports@googlegroups.com,v8-mips-ports@googlegroups.com,v8-ppc-ports@googlegroups.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1644283002
Cr-Commit-Position: refs/heads/master@{#33601}
The CL #32908 (https://codereview.chromium.org/1526293002) updated the Float64 test data and cause the RunFloat64Add and RunFloat64Sub test cases failed.
The reason is same as the CL #31808 (issue 1430943002, X87: Change the test case for X87 float operations), please refer: https://codereview.chromium.org/1430943002/
Here is the key comments from CL #31808
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 for RunFloat64Add and RunFloat64Sub.
Such as: volatile double expect = *i +/- *j; // *i +/- *j, etc.
BUG=
Review URL: https://codereview.chromium.org/1533593003
Cr-Commit-Position: refs/heads/master@{#32988}
TryTruncateFloat32ToUint64 converts a float32 to a uint64. Additionally it
provides an optional second return value which indicates whether the conversion
succeeded (i.e. float32 value was within uint64 range) or not.
I implemented the new operator on x64, arm64, and mips64. @v8-ppc-ports, can you
please take care of the ppc64 implementation of the second output?
Additionally I fixed a bug on x64 and mips64 in the implementation of
TryTruncateFloat64ToUint64. Cases where the input value was between -1 and 0
were handled incorrectly.
R=titzer@chromium.org, v8-arm-ports@googlegroups.com, v8-mips-ports@googlegroups.com
Review URL: https://codereview.chromium.org/1512023002
Cr-Commit-Position: refs/heads/master@{#32796}
MachineType is now a class with two enum fields:
- MachineRepresentation
- MachineSemantic
Both enums are usable on their own, and this change switches some places from using MachineType to use just MachineRepresentation. Most notably:
- register allocator now uses just the representation.
- Phi and Select nodes only refer to representations.
Review URL: https://codereview.chromium.org/1513543003
Cr-Commit-Position: refs/heads/master@{#32738}
This operator now provides a second output which indicates whether the
conversion from float32 to int64 was successful or not. The second output
returns 0 if the conversion fails, or something else if the conversion succeeds.
The second output can be ignored, which means that the operator can be used the
same as the original operator.
I implement the new operator on x64, arm64, and mips64. @v8-ppc-ports, can you
please take care of the ppc64 implementation of the second output?
R=titzer@chromium.org, v8-arm-ports@googlegroups.com, v8-mips-ports@googlegroups.com
Review URL: https://codereview.chromium.org/1504363002
Cr-Commit-Position: refs/heads/master@{#32737}
This operator now provides a second output which indicates whether the conversion from float64 to uint64 was successful or not. The second output returns 0 if the conversion fails, or something else if the conversion succeeds.
The second output can be ignored, which means that the operator can be used the same as the original operator.
I implement the new operator on x64 and arm64. @v8-mips-ports and @v8-ppc-ports, can you please take care of the mips64 and ppc64 implementation of the second output?
R=titzer@chromium.org, v8-arm-ports@googlegroups.com
Review URL: https://codereview.chromium.org/1507703002
Cr-Commit-Position: refs/heads/master@{#32705}
The new operator provides a second output which indicates whether the
conversion from float64 to int64 was successful or not. The second
output returns 0 if the conversion fails. If the conversion succeeds,
then the second output is differs from 0.
The second output can be ignored, which means that the operator can be
used the same way as the original operator.
I implemented the new operator on x64 and arm64. @v8-mips-ports and
@v8-ppc-ports, can you please take care of the mips64 and ppc64
implementation of the second output?
R=titzer@chromium.org, v8-arm-ports@googlegroups.com
Review URL: https://codereview.chromium.org/1495213003
Cr-Commit-Position: refs/heads/master@{#32653}
The TruncateFloat32ToUint64 operator converts a float32 to an uint64 using
round-to-zero rounding mode. If the input value is outside uint64 range, then
the result depends on the architecture. I provide an implementation for x64 and
arm64.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1479713003
Cr-Commit-Position: refs/heads/master@{#32379}
Reason for revert:
Unexpected error occurred.
Original issue's description:
> [turbofan] Implemented the TruncateFloat32ToInt64 TurboFan operator.
>
> The TruncateFloat32ToInt64 operator converts a float32 to an int64 using
> the round-to-zero rounding mode (truncate). If the input value is
> outside the int64 range, then the result depends on the architecture. I
> implemented the operator on x64, arm64, and mips64.
>
> R=titzer@chromium.org, jacob.bramley@arm.com
>
> Committed: https://crrev.com/1df1066c3c77464d2a68d7c8d501a5a0f3ad195a
> Cr-Commit-Position: refs/heads/master@{#32315}
TBR=jacob.bramley@arm.com,titzer@chromium.org,v8-mips-ports@googlegroups.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1475343002
Cr-Commit-Position: refs/heads/master@{#32316}
The TruncateFloat32ToInt64 operator converts a float32 to an int64 using
the round-to-zero rounding mode (truncate). If the input value is
outside the int64 range, then the result depends on the architecture. I
implemented the operator on x64, arm64, and mips64.
R=titzer@chromium.org, jacob.bramley@arm.com
Review URL: https://codereview.chromium.org/1476063002
Cr-Commit-Position: refs/heads/master@{#32315}
The Float32RoundTiesEven operator rounds float32 numbers towards the nearest
integer. If the distance to two integers is the same, then the result is
the even integer. This is the default rounding mode of the ieee 754 floating
point standard.
I implemented the optional Float32RoundTiesEven operator on x64, ia32, arm, and arm64.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1477753002
Cr-Commit-Position: refs/heads/master@{#32308}
The Float32RoundTruncate operator rounds float32 numbers towards zero.
The operator is currently implemented on x64, ia32, arm, and arm64.
Additionally I added support for the float32 vrintz, vrintn, and vrinta
instructions to the arm simulator.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1468303005
Cr-Commit-Position: refs/heads/master@{#32301}
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}
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}
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}
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}
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}
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 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}
Adds support for loading from and storing to outer context
variables. Also adds support for declaring functions on contexts and
locals. Finally, fixes a couple of issues with StaContextSlot where
we weren't emitting the write barrier and therefore would crash in the
GC.
Also added code so that --print-bytecode will output the
function name before the bytecodes, and replaces MachineType with StoreRepresentation in RawMachineAssembler::Store and updates tests.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1425633002
Cr-Commit-Position: refs/heads/master@{#31584}
This is to support WebAssembly 64-bit ints in the short term, since it
currently uses CheckedLoad/CheckedStore for accesses to the memory. In the
long run, we'll change this to be explicit bounds checks that throw on out
of bounds.
R=bmeurer@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1310323006
Cr-Commit-Position: refs/heads/master@{#30555}
TurboFan is now a requirement and supported by all backends, so we don't
need those macros (plus all the machinery on top) anymore.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1282763002
Cr-Commit-Position: refs/heads/master@{#30082}
We actually need round to zero truncation to implement the counterpart
of LDoubleToI in TurboFan, which tries to convert a double to an integer
as required for keyed load/store optimizations.
Drive-by-cleanup: Reduce some code duplication in the InstructionSelector
implementations.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1225993002
Cr-Commit-Position: refs/heads/master@{#29527}
This makes usage of the MachineOperatorBuilder more robust, as it will be
an error to request an unsupported operator.
Along the way, I noticed that all 7 platforms support Float32Abs and
Float64Abs. Should make them non-optional in another CL?
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1128133003
Cr-Commit-Position: refs/heads/master@{#29223}
Frame Elider requires a sane CFG which should have such dummy end block.
BUG=
Review URL: https://codereview.chromium.org/1166293004
Cr-Commit-Position: refs/heads/master@{#28911}
These operators compute the absolute floating point value of some
arbitrary input, and are implemented without any branches (i.e. using
vabs on arm, and andps/andpd on x86).
R=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/1066393002
Cr-Commit-Position: refs/heads/master@{#27662}
We can use xorps/xorpd on Intel CPUs to flip the sign bit. Ideally we'd
use a RIP-relative 128-bit constant in the code object, as OCaml/GCC
does, however that requires 128-bit alignment for code objects, which is
not yet implemented. So for now we materialize the mask inline.
R=dcarney@chromium.org
Review URL: https://codereview.chromium.org/1046893002
Cr-Commit-Position: refs/heads/master@{#27611}
This adds the basics necessary to support float32 operations in TurboFan.
The actual functionality required to detect safe float32 operations will
be added based on this later. Therefore this does not affect production
code except for some cleanup/refactoring.
In detail, this patchset contains the following features:
- Add support for float32 operations to arm, arm64, ia32 and x64
backends.
- Add float32 machine operators.
- Add support for float32 constants to simplified lowering.
- Handle float32 representation for phis in simplified lowering.
In addition, contains the following (related) cleanups:
- Fix/unify naming of backend instructions.
- Use AVX comparisons when available.
- Extend ArchOpcodeField to 9 bits (required for arm64).
- Refactor some code duplication in instruction selectors.
BUG=v8:3589
LOG=n
R=dcarney@chromium.org
Review URL: https://codereview.chromium.org/1044793002
Cr-Commit-Position: refs/heads/master@{#27509}
Provide an intrinsic %MathFloor / %_MathFloor that is used to optimize
both Math.ceil and Math.floor, and use the JS inlining mechanism to
inline Math.ceil into TurboFan code. Although we need to touch code
outside of TurboFan to make this work, this does not affect the way we
handle Math.ceil and/or Math.floor in CrankShaft, because for CrankShaft
the old-style builtin function id based inlining still kicks in first.
Once this solution is stabilized, we can use it for Math.floor as well.
And once that is settled, we can establish it as the unified way to
inline builtins, and get rid of the specialized builtin function id
based inlining at some point.
Note that "builtin" applies to basically every piece of internal
JavaScript/intrinsics based code, so this also applies to the yet to be
defined JavaScript based code stubs and handlers.
BUG=v8:3953
LOG=n
R=yangguo@chromium.org,svenpanne@chromium.org
Review URL: https://codereview.chromium.org/990963003
Cr-Commit-Position: refs/heads/master@{#27086}
This adds support for the double bits intrinsics to TurboFan, and is
a first step towards fast Math functions inlined into TurboFan code
or even compiled by themselves with TurboFan.
Review URL: https://codereview.chromium.org/974313002
Cr-Commit-Position: refs/heads/master@{#27006}
This adds a new ControlFlowOptimizer that - for now - recognizes chains
of Branches generated by the SwitchBuilder for a subset of javascript
switches into Switch nodes. Those Switch nodes are then lowered to
either table or lookup switches.
Also rename Case to IfValue (and introduce IfDefault) for consistency.
BUG=v8:3872
LOG=n
Review URL: https://codereview.chromium.org/931623002
Cr-Commit-Position: refs/heads/master@{#26691}
Adds Switch and Case operators to TurboFan and handles them
appropriately in instruction selection and code generation.
BUG=v8:3872
LOG=n
Review URL: https://codereview.chromium.org/892513003
Cr-Commit-Position: refs/heads/master@{#26515}
Use std::numeric_limits<double>::quiet_NaN() and
std::numeric_limits<float>::quiet_NaN() instead.
Review URL: https://codereview.chromium.org/864803002
Cr-Commit-Position: refs/heads/master@{#26195}
This utility will be used to simplify Linkage and fix representation inference
to work with graphs where parameters and return values are something other
than tagged. It will also make testing representation inference a lot
easier, since we can then exactly nail down the machine types of parameters
and returns.
This CL also adds c-signature.h, which demonstrates how to convert C function
signatures into MachineSignatures. The CSignatures will be used in tests to
make it easier and simpler to codegen tests.
R=jarin@chromium.org
BUG=
Review URL: https://codereview.chromium.org/515173002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23490 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
