[aarch64-port-dev ] Ping: RFR(M): 8086069: Adapt runtime calls to recent intrinsics to pass ints as long

[John Rose]

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