x86-64 stub calling convention

[Vladimir Kozlov]

It is only used in 32-bit VM to avoid additional code to handle x87 FPU stack around the call to a method which does not 
use FPU. In 64-bit VM it is NOP. Look on mach nodes definitions for CallLeaf and CallLeafNoFP in .ad files. So in your 
case you can set RC_NO_FP flag since you don't use FPU.

Vladimir

On 7/1/12 2:48 PM, Deneau, Tom wrote:
> A related question...
>
> In what cases can the flag bit RC_NO_FP be set when used with make_runtime_call?
> Can it be set when xmm registers are used, but they are only used for integer operations?
>
> -- Tom
>
>
> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Saturday, June 30, 2012 9:35 PM
> To: Deneau, Tom
> Cc: Krystal Mok; hotspot-compiler-dev at openjdk.java.net
> Subject: Re: x86-64 stub calling convention
>
> Currently we use CallRuntime nodes for calling stubs and we use it for calls into runtime (C compiled code) that is why
> it uses C calling convention. We have RFE to create special calling convention for stubs to pass arguments in registers
> even in 32-bit VM but we never had time to do it.
>
> Vladimir
>
> On 6/30/12 7:08 PM, Deneau, Tom wrote:
>> OK, thanks, Vladimir.
>> Is there a good reason for using the OS's C calling convention for stubs?
>> (as opposed to, say, using whatever makes the most sense for Java).
>>
>> -- Tom
>>
>>
>> -----Original Message-----
>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>> Sent: Friday, June 29, 2012 10:46 PM
>> To: Krystal Mok
>> Cc: Deneau, Tom; hotspot-compiler-dev at openjdk.java.net
>> Subject: Re: x86-64 stub calling convention
>>
>> I was not right that you can use all XMM registers. On windows64 only xmm0-xmm5 are available free, the rest are SOE
>> (save on entry). For stabs calls we use C calling convention. It is described in .ad file where XMM registers are
>> defined (second parameter):
>>
>> // Linux ABI:   No register preserved across function calls
>> //              XMM0-XMM7 might hold parameters
>> // Windows ABI: XMM6-XMM15 preserved across function calls
>> //              XMM0-XMM3 might hold parameters
>>
>> reg_def XMM5   (SOC, SOC, Op_RegF,  5, xmm5->as_VMReg());
>> reg_def XMM5_H (SOC, SOC, Op_RegF,  5, xmm5->as_VMReg()->next());
>>
>> #ifdef _WIN64
>>
>> reg_def XMM6   (SOC, SOE, Op_RegF,  6, xmm6->as_VMReg());
>> reg_def XMM6_H (SOC, SOE, Op_RegF,  6, xmm6->as_VMReg()->next());
>> ...
>>
>> #else
>>
>> reg_def XMM6   (SOC, SOC, Op_RegF,  6, xmm6->as_VMReg());
>> reg_def XMM6_H (SOC, SOC, Op_RegF,  6, xmm6->as_VMReg()->next());
>>
>> Vladimir
>>
>> On 6/29/12 7:25 PM, Krystal Mok wrote:
>>> Hi Tom,
>>>
>>> This is something I'd like to get an answer to, too. I did see in a comment in one of the older changes [1][2] that:
>>>
>>> +       // Spill because stubs can use any register they like and it's
>>> +       // easier to restore just those that we care about.
>>>
>>> Which doesn't really sound reassuring...
>>>
>>> - Kris
>>>
>>> [1]: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/28263a73ebfb
>>> [2]: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-May/005623.html
>>>
>>> On Sat, Jun 30, 2012 at 9:27 AM, Deneau, Tom<tom.deneau at amd.com<mailto:tom.deneau at amd.com>>   wrote:
>>>
>>>       Hi --
>>>
>>>       Can someone point me to the x86-64 calling convention for stubs created
>>>       by stubGenerator?  In particular, which xmm registers if any must be preserved
>>>       and which are volatile.
>>>
>>>       -- Tom Deneau
>>>
>>>
>>
>>
>
>