PPC: [turbofan] Implemented the TruncateFloat64ToUint64 TurboFan operator.

PPC: [turbofan] Implemented the TruncateFloat64ToUint64 TurboFan operator.

Port f6e689cebbd2de36e2b38474f89b1ad37fbfbb0f

Original commit message:
    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.

R=ahaas@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=

Committed: https://crrev.com/bc5e7fc335721f05b0c5d184c37b5685ba99ad38
Cr-Commit-Position: refs/heads/master@{#32181}

[MTBrandyberry, 2015-11-19 23:33:21]

The CQ bit was checked by mbrandy@us.ibm.com to run a CQ dry run

[commit-bot: I haz the power, 2015-11-19 23:33:25]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1460093002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1460093002/1

[commit-bot: I haz the power, 2015-11-19 23:52:58]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-11-19 23:52:59]

Dry run: This issue passed the CQ dry run.

[ahaas, 2015-11-20 07:45:33]

https://codereview.chromium.org/1460093002/diff/1/src/compiler/ppc/instructio...
File src/compiler/ppc/instruction-codes-ppc.h (right):

https://codereview.chromium.org/1460093002/diff/1/src/compiler/ppc/instructio...
src/compiler/ppc/instruction-codes-ppc.h:91: V(PPC_DoubleToUInt64)            \
nits: s/PPC_DoubleToUInt64/PPC_DoubleToUint64/

https://codereview.chromium.org/1460093002/diff/1/src/ppc/macro-assembler-ppc.cc
File src/ppc/macro-assembler-ppc.cc (right):

https://codereview.chromium.org/1460093002/diff/1/src/ppc/macro-assembler-ppc...
src/ppc/macro-assembler-ppc.cc:730: MovDoubleToInt64(dst, double_dst);
I wonder if it wouldn't be better to have this MovDoubleToInt64 in
code-generator-ppc.cc.

[MTBrandyberry, 2015-11-20 19:38:23]

https://codereview.chromium.org/1460093002/diff/1/src/compiler/ppc/instructio...
File src/compiler/ppc/instruction-codes-ppc.h (right):

https://codereview.chromium.org/1460093002/diff/1/src/compiler/ppc/instructio...
src/compiler/ppc/instruction-codes-ppc.h:91: V(PPC_DoubleToUInt64)            \
On 2015/11/20 07:45:33, ahaas wrote:
> nits: s/PPC_DoubleToUInt64/PPC_DoubleToUint64/

Done.

https://codereview.chromium.org/1460093002/diff/1/src/ppc/macro-assembler-ppc.cc
File src/ppc/macro-assembler-ppc.cc (right):

https://codereview.chromium.org/1460093002/diff/1/src/ppc/macro-assembler-ppc...
src/ppc/macro-assembler-ppc.cc:730: MovDoubleToInt64(dst, double_dst);
On 2015/11/20 07:45:33, ahaas wrote:
> I wonder if it wouldn't be better to have this MovDoubleToInt64 in
> code-generator-ppc.cc.

As the interface is written for its sole use (convert floating point to fixed),
I think the move should stay in the macro.

I do see an argument to conditionally omit the move as an optimization if the
result is used only as the source for a store instruction.  We'll consider that
for a future CL.

[michael_dawson, 2015-11-23 14:26:14]

On 2015/11/20 19:38:23, mtbrandyberry wrote:
>
https://codereview.chromium.org/1460093002/diff/1/src/compiler/ppc/instructio...
> File src/compiler/ppc/instruction-codes-ppc.h (right):
> 
>
https://codereview.chromium.org/1460093002/diff/1/src/compiler/ppc/instructio...
> src/compiler/ppc/instruction-codes-ppc.h:91: V(PPC_DoubleToUInt64)           
\
> On 2015/11/20 07:45:33, ahaas wrote:
> > nits: s/PPC_DoubleToUInt64/PPC_DoubleToUint64/
> 
> Done.
> 
>
https://codereview.chromium.org/1460093002/diff/1/src/ppc/macro-assembler-ppc.cc
> File src/ppc/macro-assembler-ppc.cc (right):
> 
>
https://codereview.chromium.org/1460093002/diff/1/src/ppc/macro-assembler-ppc...
> src/ppc/macro-assembler-ppc.cc:730: MovDoubleToInt64(dst, double_dst);
> On 2015/11/20 07:45:33, ahaas wrote:
> > I wonder if it wouldn't be better to have this MovDoubleToInt64 in
> > code-generator-ppc.cc.
> 
> As the interface is written for its sole use (convert floating point to
fixed),
> I think the move should stay in the macro.
> 
> I do see an argument to conditionally omit the move as an optimization if the
> result is used only as the source for a store instruction.  We'll consider
that
> for a future CL.

lgtm

[MTBrandyberry, 2015-11-23 14:37:14]

The CQ bit was checked by mbrandy@us.ibm.com

[commit-bot: I haz the power, 2015-11-23 14:37:27]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1460093002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1460093002/20001

[commit-bot: I haz the power, 2015-11-23 15:03:58]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-11-23 15:04:04]

Patchset 2 (id:??) landed as
https://crrev.com/bc5e7fc335721f05b0c5d184c37b5685ba99ad38
Cr-Commit-Position: refs/heads/master@{#32181}