[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re: target/ppc: bug in optimised vsl/vsr implementation?
From: |
Paul Clarke |
Subject: |
Re: Re: target/ppc: bug in optimised vsl/vsr implementation? |
Date: |
Mon, 30 Sep 2019 09:34:17 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 |
On 9/28/19 5:17 PM, Aleksandar Markovic wrote:
> Also, check on the hardware the behavior listed as 'undefined' for vsl/vsr
> in the docs - even though it is tehnically irrelevant, I am courious
> whether the old or the new (or none of them) solution match the hardware.
There does appear to be some odd behavior when one strays into the undefined.
For example:
source vector: 0102030405060708090a0b0c0d0e0f10
shift vector: 01020101010101010101010101010101
after vsl: 020806080a0c0e10121416181a1c1e20
...this appears to use the byte-respective shift values
using vsr with that result and the same shift vector:
after vsr: 0182030405060708090a0b0c0d0e0f10
I expected to get back a result matching the source vector, but somehow, an
extra bit got set.
It would probably take some more thorough investigation to map out the
undefined behavior, but I doubt there's any value to that.
PC