Ping: RFR(M): 8086069: Adapt runtime calls to recent intrinsics to pass ints as long

[Dean Long]

This may be a dumb (but hopefully related) question, but why do we need 
to add top() for _LP64:

4364 #ifdef _LP64
4365 #define XTOP ,top() /*additional argument*/
4366 #else  //_LP64
4367 #define XTOP        /*no additional argument*/
4368 #endif //_LP64

4396  make_runtime_call(RC_LEAF|RC_NO_FP,
4397                    OptoRuntime::fast_arraycopy_Type(),
4398                    StubRoutines::unsafe_arraycopy(),
4399                    "unsafe_arraycopy",
4400                    TypeRawPtr::BOTTOM,
4401                    src, dst, size XTOP);

And why only for"size", but not "src" and "dst"?

dl

On 6/15/2015 1:47 PM, John Rose wrote:
> This change surprises me.  Sometimes our machine-independent IR needs #ifdefs, Matcher queries, or flag tests to deal with platform stuff we haven't factorized properly.  In this case a flag test is "apologizing" for oddly-sized argument registers at the IR level.
>
> But TypeFuncs and the rest of the IR do not talk about such details of calling conventions.  A C2 type is only about the information content  of arguments and return values, not their register bindings.  The lower level function SharedRuntime::c_calling_convention determines exact bindings of values to argument and return value registers, using the type VMRegPair.  It is likely that there is some awkwardness in assigning a *pair* of regs (representing a single 64-bit register) to carry a 32-bit value, but surely this is less complex, and more to the point, than hacking conversions from 32- to 64-bit values at the IR level.
>
> I would expect that, if your approach is to work, there should be an assert in SharedRuntime::c_calling_convention saying that the 32-bit types T_INT, etc., are *never* presented to the SR::ccc/VMRegPair layer of the code.  But, as it seems to me, it would be less disruptive to the overall design if SR::ccc can be presented with T_INT types, and be free to return an indication of which 64-bit register will carry that value.  The low-level move instructions which push data into those argument registers can be specialized to those target registers (in the AD file) if there is a need for filling up the 32 extra bits (sign or zero).
>
> HTH
> — John
>
> On Jun 15, 2015, at 8:30 AM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
>> Hi,
>>
>> Could someone please have a look at this change?
>>
>> I had a look whether I can push the functionality down to make_runtime_call().
>> This would simplify matters a lot. But as the TypeFunc is hashed, I can not
>> change it any more in make_runtime_call().
>>
>> @aarch-people: I saw you have CCallingConventionRequiresIntsAsLongs set.
>> Could you please check whether this breaks your intinsics, e.g., multiplyToLen?
>> (We assure in sharedRuntime_ppc.cpp, c_calling_convention() that no INT types
>> end up there.)
>>
>> Thanks,
>>   Goetz
>>
>> -----Original Message-----
>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz
>> Sent: Dienstag, 9. Juni 2015 17:18
>> To: HotSpot Developers
>> Subject: RFR(M): 8086069: Adapt runtime calls to recent intrinsics to pass ints as long
>>
>> Hi,
>>
>> we are working on porting the recently* added intrinsics to PPC.  As these use
>> runtime calls, the calls must obey to the platform ABI, which requires that ints
>> are passed as longs.
>>
>> We made a similar change in "8024342: PPC64 (part 111): Support for C calling
>> conventions that require 64-bit ints."  It adapts the calls if
>> CCallingConventionRequiresIntsAsLongs is set.
>>
>> This change adapts the calls to multiplyToLen, CRC32, AES, SHA accordingly.
>>
>> Please review this change.  I please need a sponsor.
>> http://cr.openjdk.java.net/~goetz/webrevs/8086069-call_conv/webrev.01/
>>
>> Best regards,
>>   Goetz
>>
>>
>> * i.e., added after making our initial port