[foreign] RFR: 8223808: initial port for AArch64

Nick Gasson nick.gasson at arm.com
Mon May 20 06:47:27 UTC 2019


Hi Maurizio,

On 15/05/2019 17:51, Maurizio Cimadamore wrote:
> 
> This seems a good direction to explore.
> 
> I believe that, in general, our assumption that platforms have similar 
> registers classes is only partially valid. This is visible with X87 
> register, which doesn't really make sense on a non-intel machine.
> 
> But adding a class as the code is now can be problematic, as there's a 
> 1-1 correspondence between these and ShuffleRecipeClass, which is also 
> shared for all platforms.
> 
> How did you go about changing that class?
> 
> I think it could be better, for now, to stick with some hacky solution 
> like the one you proposed above, which keeps current (broken) assumption 
> and then revisit later a way to make the code better/more direct?
> 

I've made two separate patches to implement this, please have a look to 
see which is preferable. The first patch uses the integer argument 
class. This puts the the indirect argument at offset 8, which otherwise 
isn't used for an integer argument. We also now need to sort the 
bindings when generating the shuffle recipe, as Jorn pointed out.

[1] http://cr.openjdk.java.net/~ngasson/foreign/8223808/struct-integer-arg/

The second patch adds a new storage class to represent the indirect 
result register. But the downside is we need to change the x86 code to 
ignore this.

[2] 
http://cr.openjdk.java.net/~ngasson/foreign/8223808/struct-new-indirect-class/

I actually think [1] may be better as it doesn't touch the x86 code and 
is a smaller diff overall?

I've also done a minor cleanup of the original patch. This disables the 
tests that use long double on AArch64 for now.

http://cr.openjdk.java.net/~ngasson/foreign/8223808/webrev.1/

The StructUpcall test will pass with either patch [1] or [2] above but 
only when using the universal invoker. I'm wondering whether we should 
disable the direct invoker fast path on AArch64 to match Windows, as 
this will be replaced later anyway? Or is it better to try to fix it?

Thanks,
Nick


More information about the panama-dev mailing list