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

John Rose 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).

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 makeruntimecall(). This would simplify matters a lot. But as the TypeFunc is hashed, I can not change it any more in makeruntimecall(). @aarch-people: I saw you have CCallingConventionRequiresIntsAsLongs set. Could you please check whether this breaks your intinsics, e.g., multiplyToLen? (We assure in sharedRuntimeppc.cpp, ccallingconvention() 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-callconv/webrev.01/ Best regards, Goetz

* i.e., added after making our initial port

More information about the hotspot-dev mailing list