RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics

[Deshpande, Vivek R]

Hi Christian

Just calling SharedRuntime function kills the address in memory where there is jump (shown below) after the routine finishes and also need to make sure stack pointer is 16 byte aligned. So calling mathfunc() to take care of that instead of fp_runtime_fallback() which has extra overhead of storing/ restoring all the registers and xmm registers.

444   __ pop(rax);
445   __ mov(rsp, r13);
446   __ jmp(rax);

Regards,
Vivek

From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
Sent: Monday, April 18, 2016 12:15 PM
To: Deshpande, Vivek R
Cc: Vladimir Kozlov; hotspot compiler
Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics


On Apr 18, 2016, at 8:38 AM, Deshpande, Vivek R <vivek.r.deshpande at intel.com<mailto:vivek.r.deshpande at intel.com>> wrote:

Hi Christian

I have added this. Just moved generate_libmTan() after sin and cos generation.
if (vmIntrinsics::is_intrinsic_available(vmIntrinsics::_dtan)) {
  StubRoutines::_dtan = generate_libmTan();
}


Sorry, I missed this.  I should have used the browser’s search instead of eyeballing it.
src/cpu/x86/vm/macroAssembler_x86.cpp
fp_runtime_fallback is unused now:

cthaling at macbook:~/ws/jdk9/hs-comp$ ack fp_runtime_fallback hotspot/src/
hotspot/src/cpu/x86/vm/macroAssembler_x86.cpp
5625:void MacroAssembler::fp_runtime_fallback(address runtime_entry, int nb_args, int num_fpu_regs_in_use) {
5828:      fp_runtime_fallback(CAST_FROM_FN_PTR(address, SharedRuntime::dsin), 1, num_fpu_regs_in_use);
5833:      fp_runtime_fallback(CAST_FROM_FN_PTR(address, SharedRuntime::dcos), 1, num_fpu_regs_in_use);
5838:      fp_runtime_fallback(CAST_FROM_FN_PTR(address, SharedRuntime::dtan), 1, num_fpu_regs_in_use);

hotspot/src/cpu/x86/vm/macroAssembler_x86.hpp
995:  void fp_runtime_fallback(address runtime_entry, int nb_args, int num_fpu_regs_in_use);


src/cpu/x86/vm/templateInterpreterGenerator_x86_64.cpp

-      __ call(RuntimeAddress(CAST_FROM_FN_PTR(address, SharedRuntime::dexp)));

+      mathfunc(CAST_FROM_FN_PTR(address, SharedRuntime::dexp));
I understand what it’s doing but we are calling the same methods as before.  What has changed?


Regards,
Vivek

From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
Sent: Monday, April 18, 2016 11:35 AM
To: Deshpande, Vivek R <vivek.r.deshpande at intel.com<mailto:vivek.r.deshpande at intel.com>>
Cc: hotspot compiler <hotspot-compiler-dev at openjdk.java.net<mailto:hotspot-compiler-dev at openjdk.java.net>>; Vladimir Kozlov <vladimir.kozlov at oracle.com<mailto:vladimir.kozlov at oracle.com>>; Viswanathan, Sandhya <sandhya.viswanathan at intel.com<mailto:sandhya.viswanathan at intel.com>>
Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics


On Apr 18, 2016, at 7:38 AM, Deshpande, Vivek R <vivek.r.deshpande at intel.com<mailto:vivek.r.deshpande at intel.com>> wrote:

Hi all

I would like to contribute a patch which helps to control the intrinsics in interpreter, c1 and c2 by disabling the stub generation.
This uses -XX:DisableIntrinsic option to achieve the same.
Could you please review and sponsor this patch.

Bug-id:
https://bugs.openjdk.java.net/browse/JDK-8154473
webrev:
http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.00/

src/cpu/x86/vm/stubGenerator_x86_64.cpp

+      if (vmIntrinsics::is_intrinsic_available(vmIntrinsics::_dpow)) {

       StubRoutines::_dpow = generate_libmPow();

-      StubRoutines::_dtan = generate_libmTan();

+      }
Was removing libmTan on purpose?




Thanks and regards,
Vivek

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160418/764c050e/attachment-0001.html>