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

[Christian Thalinger]

> On Apr 18, 2016, at 10:28 AM, Deshpande, Vivek R <vivek.r.deshpande at intel.com> wrote:
> 
> 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);
>  

Ok, that makes sense.

> 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 <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 <https://bugs.openjdk.java.net/browse/JDK-8154473>
> webrev:
> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.00/ <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/c98f1cd3/attachment-0001.html>