[aarch64-port-dev ] RFR: 88158361: AArch64: Address calculation missed optimizations

[Andrew Haley]

Hi,

On 27/06/17 03:50, Zhongwei Yao wrote:
> On 26 June 2017 at 19:17, Andrew Haley <aph at redhat.com> wrote:
> 
>> On 23/06/17 10:50, Zhongwei Yao wrote:
>>>
>>> Besides pass jtreg on aarch64 and x86, for each pattern, I added one or
>> two
>>> test cases, which will hit the testing pattern. And check the test cases'
>>> assembly output to ensure the hit pattern generates correct instructions.
>>>
>>> Here is a test case for: AddExtL_uxtb_and_shift pattern:
>>>
>>> // testrule: AddExtL_uxtb_and_shift
>>> // geninst: add.*x.*, x.*, w.*, uxtb #3
>>> public Flonglong adduxtb = new Flonglong() {
>>> public long func(long x, long y) {
>>> return y + ((x & 255) << 3);
>>> }
>>> };
>>>
>>> And the "geninst" line defines this case's required generated assembly
>>> instruction pattern.
>>>
>>> A script will check whether this case's generated C2 assembly has the
>>> required instruction "add.*x.*, x.*, w.*, uxtb #3". If yes, the test
>>> passes. And if there is a "nosense" on "// testrule" line, such check is
>>> skipped.
>>>
>>> All test cases are at http://cr.openjdk.java.net/~
>> njian/8158361/ExtTest.java
>>
>> This looks great, just one problem.
>>
>> I'm seeing this with current JDK10 HotSpot:
>>
>>   0x000003ff95285b64: and       x10, x2, #0xff
>>   0x000003ff95285b68: add       x0, x3, x10, lsl #3  ;*ladd {reexecute=0
>> rethrow=0 return_oop=0}
>>                                                 ; - ExtTest$1::func at 8
>> (line 25)
>>
>> This happens in three of the patterns.
>>
>>     public Flonglong adduxtb = new Flonglong() {
>>         public long func(long x, long y) {
>>             return y + ((x & 255) << 3);
>>         }
>>     };
>>
>>     public Flonglong adduxtb2 = new Flonglong() {
>>        public long func(long x, long y) {
>>            return y + (((x << 56) >>> 56) << 4);
>>        }
>>     };
>>
>>     public Flonglong subuxtb2 = new Flonglong() {
>>        public long func(long x, long y) {
>>            return y - (((x << 56) >>> 56) << 4);
>>        }
>>     };
>>
> 
> It is strange, because I haven't seen such pattern locally.

I found the bug that caused this not to be matched, and it's a bug that
you fixed.  In jdk9-dev/hotspot, I see:

operand immL_255()
%{
  predicate(n->get_int() == 255);
  match(ConI);

  op_cost(0);
  format %{ %}
  interface(CONST_INTER);
%}

It's because this patch was not back-ported to JDK9:

# HG changeset patch
# User njian
# Date 1494572375 -28800
#      Fri May 12 14:59:35 2017 +0800
# Node ID 94302da0a7beb0482afb977f1290062fff5ddb7a
# Parent  717a2b9c928a28f6d396e811463e0718c794732f
8179933: AArch64: Incorrect match rule for immL_255
Summary: The match rule fix will enable instructs like: SubExtL_uxtb_and and AddExtL_uxtb_and etc. Also rename immL_63 to the proper name: immI_63.
Reviewed-by: aph
Contributed-by: zhongwei.yao at linaro.org

Once we have a jdk9u tree, we should apply these patches to it.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671