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

[Lindenmaier, Goetz]

Hi John,

thanks for looking at this change!

The PPC ABI says that int arguments must properly be extended to 64-bit:
http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#PARAM-PASS
"Simple integer types (char, short, int, long, enum) are mapped to a single doubleword. Values shorter than a doubleword are sign or zero extended as necessary."

We achieve this by adding an I2L node for arguments < 64-bit.
To assure proper typing of the IR, we have to adapt the function type and parameter list
accordingly.
Obviously, we have to deal with the fact that longs occupy 2 slots. That's not nice, 
but currently necessary.

The assertion you mention is in sharedRuntime_ppc.cpp:738. 

The approach works, it's just not implemented for the new intrinsics.
Also, I was looking for a generic solution, where I don't have to adapt
each runtime call added to the parser.

Sure we could issue sign extending instructions along with the call node
during emitting to the code buffer.  But if we add this early during parsing, the
nodes are subject to optimization.

Best regards,
  Goetz.



-----Original Message-----
From: John Rose [mailto:john.r.rose at oracle.com] 
Sent: Montag, 15. Juni 2015 22:47
To: Lindenmaier, Goetz
Cc: HotSpot Developers; aarch64-port-dev at openjdk.java.net
Subject: Re: Ping: RFR(M): 8086069: Adapt runtime calls to recent intrinsics to pass ints as long

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