Ping: RFR(M): 8086069: Adapt runtime calls to recent intrinsics to pass ints as long
dean.long at oracle.com
Tue Jun 16 00:07:34 UTC 2015
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
4401 src, dst, size XTOP);
And why only for"size", but not "src" and "dst"?
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).
> — John
> On Jun 15, 2015, at 8:30 AM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
>> 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.)
>> -----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
>> 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.
>> Best regards,
>> * i.e., added after making our initial port
More information about the hotspot-dev