Ping: RFR(M): 8086069: Adapt runtime calls to recent intrinsics to pass ints as long
john.r.rose at oracle.com
Mon Jun 15 20:47:17 UTC 2015
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).
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