[foreign] RFR: 8223808: initial port for AArch64

[Maurizio Cimadamore]

On 15/05/2019 07:23, Nick Gasson wrote:
> Hi Jorn and Maurizio,
>
> Thanks for the feedback!
>
>>>
>>> If r8 is the first integer argument register this would work, but 
>>> this doesn't seem to be the case? I think a quick-fix for this is 
>>> adding a sorting pass of the bindings by storage index to 
>>> CallingSequenceBuilder::build. 
>
> This works but now it seems a bit of a kludge as r8 isn't normally an 
> integer argument register.
>
>>
>> Right - it seems like we should have separate treatment for return in 
>> memory bindings in CallingSequenceBuilder too - e.g. instead of 
>> assume that we can just add another argument binding for it, we 
>> should add a 'return in memory' binding (which then on Windows/SysV 
>> will just delegate to addArgumentBindings).
>>
>
> Do you mean add a separate BindingsComputer for returns in memroy 
> bindings?
Yes
>
>
> I tried a different approach today of adding a new StorageClass 
> INDIRECT_RESULT_REGISTER that is used in 
> StorageCalculator::addBindings if forArguments && arg.argumentIndex() 
> == -1. And then in universalNativeInvoker_aarch64.cpp we can load this 
> directly into r8.
>
> This seems quite neat to me, and adding a new storage class matches 
> the ABI document more closely. Although we need to change the x86 to 
> ignore this class.

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?

Maurizio


>
> With the changes to box/unboxValue from Windowsx64ABI, the 
> StructByValueTest case passes now. If you're happy with this approach 
> I can tidy it up and update the webrev?
>
>
> Thanks,
> Nick