You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Gregory Shimansky (JIRA)" <ji...@apache.org> on 2007/08/13 12:53:43 UTC
[jira] Updated: (HARMONY-4620) [drlvm][jit] Long return path for
floating point values in calling convension
[ 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.