You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Naumova Natalya (JIRA)" <ji...@apache.org> on 2007/08/12 15:09:43 UTC
[jira] Created: (HARMONY-4620) Long return path for floating point
values in calling convension
Long return path for floating point values in calling convension
----------------------------------------------------------------
Key: HARMONY-4620
URL: https://issues.apache.org/jira/browse/HARMONY-4620
Project: Harmony
Issue Type: Improvement
Components: DRLVM
Environment: appropriate for for Intel architecture
Reporter: Naumova Natalya
DRLVM has too long return path when the return value is floatin point. The reason is FPU usage together with SSE instructions in calling convention: we have "SSE -> mem -> FPU -> (return) mem -> SSE"; return (double) value first is calculated on xmm* registers, then copied to mem, then is put on FPU stack, then extracted from this stack (in calling proc) to memory again, then again calculation is happened in xmm* registers (SSE instructions). This issue overrides the improvement with loop unrolling, overhead from the parameters passing with this calling convention overrides the loop body doubling speed-up. When you increase "arg.optimizer.unroll.medium_loop_unroll_count" option in method where return value is double and it is in loop, then you'll have degradation (example - MonteCarlo benchmark in SciMark).
Can we avoid using FPU with SSE in this case?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-4620) [drlvm][jit] Long return path for
floating point values in calling convention
Posted by "Alexey Varlamov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575265#action_12575265 ]
Alexey Varlamov commented on HARMONY-4620:
------------------------------------------
Evgueni, AFAICS you've also fixed HARMONY-5152 in the suggested patch, thanks!
However I do have compatibility concerns, do we really want to cut off completely non-SSE CPUs support?
The best solution would be defining one more SSE-based managed CC and providing runtime customization to switch between them, accordingly to host architecture. However there is no such customization machinery available in the VM yet, so as a bare minimum we should keep compile-time switch, e.g. ifdef SSE/FPU return path.
Could you please add such ifdefs to the patch?
> [drlvm][jit] Long return path for floating point values in calling convention
> -----------------------------------------------------------------------------
>
> Key: HARMONY-4620
> URL: https://issues.apache.org/jira/browse/HARMONY-4620
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Environment: appropriate for for Intel architecture
> Reporter: Naumova Natalya
> Assignee: Mikhail Fursov
> Attachments: return_xmm.patch, return_xmm_2.patch, return_xmm_3.patch
>
>
> DRLVM has too long return path when the return value is floatin point. The reason is FPU usage together with SSE instructions in calling convention: we have "SSE -> mem -> FPU -> (return) mem -> SSE"; return (double) value first is calculated on xmm* registers, then copied to mem, then is put on FPU stack, then extracted from this stack (in calling proc) to memory again, then again calculation is happened in xmm* registers (SSE instructions). This issue overrides the improvement with loop unrolling, overhead from the parameters passing with this calling convention overrides the loop body doubling speed-up. When you increase "arg.optimizer.unroll.medium_loop_unroll_count" option in method where return value is double and it is in loop, then you'll have degradation (example - MonteCarlo benchmark in SciMark).
> Can we avoid using FPU with SSE in this case?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-4620) [drlvm][jit] Long return path for
floating point values in calling convention
Posted by "Mikhail Fursov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577840#action_12577840 ]
Mikhail Fursov commented on HARMONY-4620:
-----------------------------------------
Regression test from H2083 is failed on EM64T Linux.
> [drlvm][jit] Long return path for floating point values in calling convention
> -----------------------------------------------------------------------------
>
> Key: HARMONY-4620
> URL: https://issues.apache.org/jira/browse/HARMONY-4620
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Environment: appropriate for for Intel architecture
> Reporter: Naumova Natalya
> Assignee: Mikhail Fursov
> Attachments: return_xmm.patch, return_xmm_2.patch, return_xmm_3.patch, return_xmm_4.patch
>
>
> DRLVM has too long return path when the return value is floatin point. The reason is FPU usage together with SSE instructions in calling convention: we have "SSE -> mem -> FPU -> (return) mem -> SSE"; return (double) value first is calculated on xmm* registers, then copied to mem, then is put on FPU stack, then extracted from this stack (in calling proc) to memory again, then again calculation is happened in xmm* registers (SSE instructions). This issue overrides the improvement with loop unrolling, overhead from the parameters passing with this calling convention overrides the loop body doubling speed-up. When you increase "arg.optimizer.unroll.medium_loop_unroll_count" option in method where return value is double and it is in loop, then you'll have degradation (example - MonteCarlo benchmark in SciMark).
> Can we avoid using FPU with SSE in this case?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (HARMONY-4620) [drlvm][jit] Long return path for
floating point values in calling convention
Posted by "Mikhail Fursov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mikhail Fursov resolved HARMONY-4620.
-------------------------------------
Resolution: Fixed
committed revision r637775
> [drlvm][jit] Long return path for floating point values in calling convention
> -----------------------------------------------------------------------------
>
> Key: HARMONY-4620
> URL: https://issues.apache.org/jira/browse/HARMONY-4620
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Environment: appropriate for for Intel architecture
> Reporter: Naumova Natalya
> Assignee: Mikhail Fursov
> Attachments: return_xmm.patch, return_xmm_2.patch, return_xmm_3.patch, return_xmm_4.patch, return_xmm_5.patch
>
>
> DRLVM has too long return path when the return value is floatin point. The reason is FPU usage together with SSE instructions in calling convention: we have "SSE -> mem -> FPU -> (return) mem -> SSE"; return (double) value first is calculated on xmm* registers, then copied to mem, then is put on FPU stack, then extracted from this stack (in calling proc) to memory again, then again calculation is happened in xmm* registers (SSE instructions). This issue overrides the improvement with loop unrolling, overhead from the parameters passing with this calling convention overrides the loop body doubling speed-up. When you increase "arg.optimizer.unroll.medium_loop_unroll_count" option in method where return value is double and it is in loop, then you'll have degradation (example - MonteCarlo benchmark in SciMark).
> Can we avoid using FPU with SSE in this case?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (HARMONY-4620) [drlvm][jit] Long return path for
floating point values in calling convension
Posted by "Mikhail Fursov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mikhail Fursov reassigned HARMONY-4620:
---------------------------------------
Assignee: Mikhail Fursov
> [drlvm][jit] Long return path for floating point values in calling convension
> -----------------------------------------------------------------------------
>
> Key: HARMONY-4620
> URL: https://issues.apache.org/jira/browse/HARMONY-4620
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Environment: appropriate for for Intel architecture
> Reporter: Naumova Natalya
> Assignee: Mikhail Fursov
> Attachments: return_xmm.patch
>
>
> DRLVM has too long return path when the return value is floatin point. The reason is FPU usage together with SSE instructions in calling convention: we have "SSE -> mem -> FPU -> (return) mem -> SSE"; return (double) value first is calculated on xmm* registers, then copied to mem, then is put on FPU stack, then extracted from this stack (in calling proc) to memory again, then again calculation is happened in xmm* registers (SSE instructions). This issue overrides the improvement with loop unrolling, overhead from the parameters passing with this calling convention overrides the loop body doubling speed-up. When you increase "arg.optimizer.unroll.medium_loop_unroll_count" option in method where return value is double and it is in loop, then you'll have degradation (example - MonteCarlo benchmark in SciMark).
> Can we avoid using FPU with SSE in this case?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-4620) [drlvm][jit] Long return path for
floating point values in calling convension
Posted by "Mikhail Fursov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mikhail Fursov updated HARMONY-4620:
------------------------------------
Attachment: return_xmm_2.patch
Evgueni, the patch runs OK on X86 platforms but fails on X86_64 on reg.tests
I attached the updated version of the patch with a fixed LIL sources location
> [drlvm][jit] Long return path for floating point values in calling convension
> -----------------------------------------------------------------------------
>
> Key: HARMONY-4620
> URL: https://issues.apache.org/jira/browse/HARMONY-4620
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Environment: appropriate for for Intel architecture
> Reporter: Naumova Natalya
> Assignee: Mikhail Fursov
> Attachments: return_xmm.patch, return_xmm_2.patch
>
>
> DRLVM has too long return path when the return value is floatin point. The reason is FPU usage together with SSE instructions in calling convention: we have "SSE -> mem -> FPU -> (return) mem -> SSE"; return (double) value first is calculated on xmm* registers, then copied to mem, then is put on FPU stack, then extracted from this stack (in calling proc) to memory again, then again calculation is happened in xmm* registers (SSE instructions). This issue overrides the improvement with loop unrolling, overhead from the parameters passing with this calling convention overrides the loop body doubling speed-up. When you increase "arg.optimizer.unroll.medium_loop_unroll_count" option in method where return value is double and it is in loop, then you'll have degradation (example - MonteCarlo benchmark in SciMark).
> Can we avoid using FPU with SSE in this case?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-4620) [drlvm][jit] Long return path for
floating point values in calling convention
Posted by "Evgueni Brevnov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Evgueni Brevnov updated HARMONY-4620:
-------------------------------------
Attachment: return_xmm_3.patch
Fixed EM64T failures. Please check one more time.
> [drlvm][jit] Long return path for floating point values in calling convention
> -----------------------------------------------------------------------------
>
> Key: HARMONY-4620
> URL: https://issues.apache.org/jira/browse/HARMONY-4620
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Environment: appropriate for for Intel architecture
> Reporter: Naumova Natalya
> Assignee: Mikhail Fursov
> Attachments: return_xmm.patch, return_xmm_2.patch, return_xmm_3.patch
>
>
> DRLVM has too long return path when the return value is floatin point. The reason is FPU usage together with SSE instructions in calling convention: we have "SSE -> mem -> FPU -> (return) mem -> SSE"; return (double) value first is calculated on xmm* registers, then copied to mem, then is put on FPU stack, then extracted from this stack (in calling proc) to memory again, then again calculation is happened in xmm* registers (SSE instructions). This issue overrides the improvement with loop unrolling, overhead from the parameters passing with this calling convention overrides the loop body doubling speed-up. When you increase "arg.optimizer.unroll.medium_loop_unroll_count" option in method where return value is double and it is in loop, then you'll have degradation (example - MonteCarlo benchmark in SciMark).
> Can we avoid using FPU with SSE in this case?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-4620) [drlvm][jit] Long return path for
floating point values in calling convension
Posted by "Evgueni Brevnov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Evgueni Brevnov updated HARMONY-4620:
-------------------------------------
Attachment: return_xmm.patch
> [drlvm][jit] Long return path for floating point values in calling convension
> -----------------------------------------------------------------------------
>
> Key: HARMONY-4620
> URL: https://issues.apache.org/jira/browse/HARMONY-4620
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Environment: appropriate for for Intel architecture
> Reporter: Naumova Natalya
> Attachments: return_xmm.patch
>
>
> DRLVM has too long return path when the return value is floatin point. The reason is FPU usage together with SSE instructions in calling convention: we have "SSE -> mem -> FPU -> (return) mem -> SSE"; return (double) value first is calculated on xmm* registers, then copied to mem, then is put on FPU stack, then extracted from this stack (in calling proc) to memory again, then again calculation is happened in xmm* registers (SSE instructions). This issue overrides the improvement with loop unrolling, overhead from the parameters passing with this calling convention overrides the loop body doubling speed-up. When you increase "arg.optimizer.unroll.medium_loop_unroll_count" option in method where return value is double and it is in loop, then you'll have degradation (example - MonteCarlo benchmark in SciMark).
> Can we avoid using FPU with SSE in this case?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-4620) [drlvm][jit] Long return path for
floating point values in calling convention
Posted by "Mikhail Fursov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mikhail Fursov updated HARMONY-4620:
------------------------------------
Attachment: return_xmm_4.patch
return_xmm_4.patch: catching latest changes in file structure.
I starting to test this patch and going to commit it in a day if no problems found.
> [drlvm][jit] Long return path for floating point values in calling convention
> -----------------------------------------------------------------------------
>
> Key: HARMONY-4620
> URL: https://issues.apache.org/jira/browse/HARMONY-4620
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Environment: appropriate for for Intel architecture
> Reporter: Naumova Natalya
> Assignee: Mikhail Fursov
> Attachments: return_xmm.patch, return_xmm_2.patch, return_xmm_3.patch, return_xmm_4.patch
>
>
> DRLVM has too long return path when the return value is floatin point. The reason is FPU usage together with SSE instructions in calling convention: we have "SSE -> mem -> FPU -> (return) mem -> SSE"; return (double) value first is calculated on xmm* registers, then copied to mem, then is put on FPU stack, then extracted from this stack (in calling proc) to memory again, then again calculation is happened in xmm* registers (SSE instructions). This issue overrides the improvement with loop unrolling, overhead from the parameters passing with this calling convention overrides the loop body doubling speed-up. When you increase "arg.optimizer.unroll.medium_loop_unroll_count" option in method where return value is double and it is in loop, then you'll have degradation (example - MonteCarlo benchmark in SciMark).
> Can we avoid using FPU with SSE in this case?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-4620) [drlvm][jit] Long return path for
floating point values in calling convention
Posted by "Evgueni Brevnov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575342#action_12575342 ]
Evgueni Brevnov commented on HARMONY-4620:
------------------------------------------
As far as I remember we agreed to support processors which has SSE at least. I believe no one tried Harmony on non-SSE processors. I don't think we should care about this case.
Thanks
Evgueni
> [drlvm][jit] Long return path for floating point values in calling convention
> -----------------------------------------------------------------------------
>
> Key: HARMONY-4620
> URL: https://issues.apache.org/jira/browse/HARMONY-4620
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Environment: appropriate for for Intel architecture
> Reporter: Naumova Natalya
> Assignee: Mikhail Fursov
> Attachments: return_xmm.patch, return_xmm_2.patch, return_xmm_3.patch
>
>
> DRLVM has too long return path when the return value is floatin point. The reason is FPU usage together with SSE instructions in calling convention: we have "SSE -> mem -> FPU -> (return) mem -> SSE"; return (double) value first is calculated on xmm* registers, then copied to mem, then is put on FPU stack, then extracted from this stack (in calling proc) to memory again, then again calculation is happened in xmm* registers (SSE instructions). This issue overrides the improvement with loop unrolling, overhead from the parameters passing with this calling convention overrides the loop body doubling speed-up. When you increase "arg.optimizer.unroll.medium_loop_unroll_count" option in method where return value is double and it is in loop, then you'll have degradation (example - MonteCarlo benchmark in SciMark).
> Can we avoid using FPU with SSE in this case?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-4620) [drlvm][jit] Long return path for
floating point values in calling convention
Posted by "Evgueni Brevnov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Evgueni Brevnov updated HARMONY-4620:
-------------------------------------
Attachment: return_xmm_5.patch
Fixed the regression test failure on Linux EM64T.
> [drlvm][jit] Long return path for floating point values in calling convention
> -----------------------------------------------------------------------------
>
> Key: HARMONY-4620
> URL: https://issues.apache.org/jira/browse/HARMONY-4620
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Environment: appropriate for for Intel architecture
> Reporter: Naumova Natalya
> Assignee: Mikhail Fursov
> Attachments: return_xmm.patch, return_xmm_2.patch, return_xmm_3.patch, return_xmm_4.patch, return_xmm_5.patch
>
>
> DRLVM has too long return path when the return value is floatin point. The reason is FPU usage together with SSE instructions in calling convention: we have "SSE -> mem -> FPU -> (return) mem -> SSE"; return (double) value first is calculated on xmm* registers, then copied to mem, then is put on FPU stack, then extracted from this stack (in calling proc) to memory again, then again calculation is happened in xmm* registers (SSE instructions). This issue overrides the improvement with loop unrolling, overhead from the parameters passing with this calling convention overrides the loop body doubling speed-up. When you increase "arg.optimizer.unroll.medium_loop_unroll_count" option in method where return value is double and it is in loop, then you'll have degradation (example - MonteCarlo benchmark in SciMark).
> Can we avoid using FPU with SSE in this case?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-4620) [drlvm][jit] Long return path for
floating point values in calling convention
Posted by "Naumova Natalya (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Naumova Natalya updated HARMONY-4620:
--------------------------------------
Summary: [drlvm][jit] Long return path for floating point values in calling convention (was: [drlvm][jit] Long return path for floating point values in calling convension)
> [drlvm][jit] Long return path for floating point values in calling convention
> -----------------------------------------------------------------------------
>
> Key: HARMONY-4620
> URL: https://issues.apache.org/jira/browse/HARMONY-4620
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Environment: appropriate for for Intel architecture
> Reporter: Naumova Natalya
> Assignee: Mikhail Fursov
> Attachments: return_xmm.patch, return_xmm_2.patch
>
>
> DRLVM has too long return path when the return value is floatin point. The reason is FPU usage together with SSE instructions in calling convention: we have "SSE -> mem -> FPU -> (return) mem -> SSE"; return (double) value first is calculated on xmm* registers, then copied to mem, then is put on FPU stack, then extracted from this stack (in calling proc) to memory again, then again calculation is happened in xmm* registers (SSE instructions). This issue overrides the improvement with loop unrolling, overhead from the parameters passing with this calling convention overrides the loop body doubling speed-up. When you increase "arg.optimizer.unroll.medium_loop_unroll_count" option in method where return value is double and it is in loop, then you'll have degradation (example - MonteCarlo benchmark in SciMark).
> Can we avoid using FPU with SSE in this case?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-4620) [drlvm][jit] Long return path for
floating point values in calling convension
Posted by "Gregory Shimansky (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gregory Shimansky updated HARMONY-4620:
---------------------------------------
Summary: [drlvm][jit] Long return path for floating point values in calling convension (was: Long return path for floating point values in calling convension)
> [drlvm][jit] Long return path for floating point values in calling convension
> -----------------------------------------------------------------------------
>
> Key: HARMONY-4620
> URL: https://issues.apache.org/jira/browse/HARMONY-4620
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Environment: appropriate for for Intel architecture
> Reporter: Naumova Natalya
>
> DRLVM has too long return path when the return value is floatin point. The reason is FPU usage together with SSE instructions in calling convention: we have "SSE -> mem -> FPU -> (return) mem -> SSE"; return (double) value first is calculated on xmm* registers, then copied to mem, then is put on FPU stack, then extracted from this stack (in calling proc) to memory again, then again calculation is happened in xmm* registers (SSE instructions). This issue overrides the improvement with loop unrolling, overhead from the parameters passing with this calling convention overrides the loop body doubling speed-up. When you increase "arg.optimizer.unroll.medium_loop_unroll_count" option in method where return value is double and it is in loop, then you'll have degradation (example - MonteCarlo benchmark in SciMark).
> Can we avoid using FPU with SSE in this case?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-4620) [drlvm][jit] Long return path for
floating point values in calling convension
Posted by "Evgueni Brevnov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568484#action_12568484 ]
Evgueni Brevnov commented on HARMONY-4620:
------------------------------------------
Do we really need to modify calling convention in this case? Could we just do FPU calculations in this case without involving SSE at all?
Thanks
Evgueni
> [drlvm][jit] Long return path for floating point values in calling convension
> -----------------------------------------------------------------------------
>
> Key: HARMONY-4620
> URL: https://issues.apache.org/jira/browse/HARMONY-4620
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Environment: appropriate for for Intel architecture
> Reporter: Naumova Natalya
>
> DRLVM has too long return path when the return value is floatin point. The reason is FPU usage together with SSE instructions in calling convention: we have "SSE -> mem -> FPU -> (return) mem -> SSE"; return (double) value first is calculated on xmm* registers, then copied to mem, then is put on FPU stack, then extracted from this stack (in calling proc) to memory again, then again calculation is happened in xmm* registers (SSE instructions). This issue overrides the improvement with loop unrolling, overhead from the parameters passing with this calling convention overrides the loop body doubling speed-up. When you increase "arg.optimizer.unroll.medium_loop_unroll_count" option in method where return value is double and it is in loop, then you'll have degradation (example - MonteCarlo benchmark in SciMark).
> Can we avoid using FPU with SSE in this case?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.