[aarch64-port-dev ] RFR: JDK-8185786: AArch64: disable some address reshapings.

[Zhongwei Yao]

Hi, all,

Is this patch OK for JDK10?



On 8 August 2017 at 18:23, Zhongwei Yao <zhongwei.yao at linaro.org> wrote:
> Hi, all,
>
> Thanks for your review and information!
>
> Patch is updated: http://cr.openjdk.java.net/~njian/8185786/webrev.01/
>
> On 5 August 2017 at 01:53, Pinski, Andrew <Andrew.Pinski at cavium.com> wrote:
>> FYI. Some future ones cause the shift to be splitted off while others will
>> not split it and still be free.
>>
>>
>>
>> Sent via the Samsung Galaxy S7 edge, an AT&T 4G LTE smartphone
>>
>>
>> -------- Original message --------
>> From: "White, Derek" <Derek.White at cavium.com>
>> Date: 8/4/17 8:33 AM (GMT-08:00)
>> To: Andrew Haley <aph at redhat.com>, Zhongwei Yao <zhongwei.yao at linaro.org>,
>> aarch64-port-dev at openjdk.java.net
>> Subject: Re: [aarch64-port-dev ] RFR: JDK-8185786: AArch64: disable some
>> address reshapings.
>>
>> FYI,
>>
>> The Cavium T88 CPU doesn't have this scaling penalty, but future CPUs may.
>>
>>  - Derek
>>
>>> -----Original Message-----
>>> From: aarch64-port-dev [mailto:aarch64-port-dev-
>>> bounces at openjdk.java.net] On Behalf Of Andrew Haley
>>> Sent: Friday, August 04, 2017 9:33 AM
>>> To: Zhongwei Yao <zhongwei.yao at linaro.org>; aarch64-port-
>>> dev at openjdk.java.net
>>> Subject: Re: [aarch64-port-dev ] RFR: JDK-8185786: AArch64: disable some
>>> address reshapings.
>>>
>>> On 04/08/17 10:48, Zhongwei Yao wrote:
>>> > Hi, all,
>>> >
>>> > Bug:
>>> > https://bugs.openjdk.java.net/browse/JDK-8185786/
>>> >
>>> > Webrev:
>>> > http://cr.openjdk.java.net/~njian/8185786/webrev.00/
>>> >
>>> > According to [1-2], ldrh/ldrsh scale by 2 is a bit slower than the
>>> > non-scale version on modern Cortex-A cores.
>>>
>>> Yes, I see.  But from what I remember, without this reshape_address()
>>> change there was some nasty code generated elsewhere.  Still, I suppose
>>> it's
>>> only for short.
>>>
>>> Is it possible to take this logic and push it into a suitable class,
>>> VM_Version,
>>> perhaps?  GCC uses a table, indexed by the mode of the operand.  We could
>>> have
>>>
>>> +        if (!u->is_Mem() || u->is_LoadVector() || u->is_StoreVector() ||
>>> u-
>>> >Opcode() == Op_StoreCM ||
>>> +            (VM_Version::expensive_access(u->Opcode()->type()),
>>> + Op_LShiftL)) {
>>>
>>> ... or something.
>>>
>>> --
>>> Andrew Haley
>>> Java Platform Lead Engineer
>>> Red Hat UK Ltd. <https://www.redhat.com>
>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>
>
>
> --
> Best regards,
> Zhongwei



-- 
Best regards,
Zhongwei