[aarch64-port-dev ] [aarch64-port-dev] [10] RFR: 8184049 : Matching rule for ubfiz

[Daniel Stewart]

New Webrev (Thanks Ningsheng!)

http://cr.openjdk.java.net/~njian/8184049/webrev.01/

Please review.

Thank you,
Daniel

On Thu, Jul 27, 2017 at 4:49 PM, Daniel Stewart <daniel.stewart at linaro.org>
wrote:

> I was able to get Andrew's test file to work as well, and it seems to be
> producing the ubfiz instructions in a  loop. I did modify his code to
> ensure that the values passed to the test functions match that which is
> expected (int, long, short). The modified run() function is below. I've
> created a new patch and it should be posted in the next few hours.
>
> public void run(String [] args) {
>         long sum = this.sum | (1 << 27);
>         int n = (int)sum;
>         n = xorshift32(n);
>         for (int i = 0; i < 1000; i++) {
>             //System.out.println((int)Math.random());
>             n += testI(n);
>             n += testI2(n);
>             n += testI3(n);
>             n += testI4(n);
>             n += testI5(n);
>         }
>         long n1 = (long)n;
>         for (int i = 0; i < 1000; i++) {
>             n1 += testL(n1);
>             n1 += testL2(n1);
>             n1 += testL3(n1);
>             n1 += testL4(n1);
>             n1 += testConv(n1);
>         }
>         short n2 = (short)n;
>         for (int i = 0; i < 1000; i++) {
>             n2 += testConv2((short)n2);
>         }
>         n1 += n2;
>         for (int i = 0; i< 1000; i++) {
>             n1 += testConv3(n);
>         }
>         this.sum += sum ^ n1;
>
> Daniel
>
>
>
> On Thu, Jul 27, 2017 at 11:13 AM, Daniel Stewart <
> daniel.stewart at linaro.org> wrote:
>
>> I'm preparing another patch right now. The issue Felix uncovered is
>> because the number of bits masked off + the shift amount is greater than
>> 32. Instead of just lopping off the bits that would shifted, this winds up
>> looking like a ubfx with the wrong bits masked off. I'm updating the
>> Predicate to catch this case. It doesn't appear to be a problem in the ubfx
>> case, as the AND'ing of the bits appears to be dropped and so the match for
>> ubfx is never even tried.
>>
>> Daniel
>>
>> On Thu, Jul 27, 2017 at 10:05 AM, Andrew Haley <aph at redhat.com> wrote:
>>
>>> On 25/07/17 14:35, Felix Yang wrote:
>>> >     I tried to modify the test case changing testI2() into:
>>> >
>>> >     public static int testI2() {
>>> >         return (ia[0] & 0xf) << 30;
>>> >     }
>>> >
>>> >     Then I got different execution results on aarch64 and x86:
>>> >
>>> > aarch64:
>>> > java -XX:-TieredCompilation Test
>>> > 2758214541841904631
>>> >
>>> > x86:
>>> > java -XX:-TieredCompilation Test
>>> > 2758195853365405696
>>>
>>> Hmm.  I'm not seeing that problem.  But on the other had, I'm not seeing
>>> the intrinsics used much either: in fact, they seem to be used only once
>>> and are not used in the loop at all.
>>>
>>> I've been using the test at
>>> http://cr.openjdk.java.net/~aph/8184049/Test.java
>>>
>>> --
>>> Andrew Haley
>>> Java Platform Lead Engineer
>>> Red Hat UK Ltd. <https://www.redhat.com>
>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>>>
>>
>>
>>
>> --
>> Daniel Stewart
>>
>
>
>
> --
> Daniel Stewart
>



-- 
Daniel Stewart