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

[Daniel Stewart]

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