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

[Zhongwei Yao]

Thanks for pointing out this issue!

On 28 June 2017 at 21:48, Andrew Haley <aph at redhat.com> wrote:

> 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
>



-- 
Best regards,
Zhongwei