|
From: | Aleksandar Markovic |
Subject: | Re: Re: target/ppc: bug in optimised vsl/vsr implementation? |
Date: | Mon, 30 Sep 2019 16:53:09 +0200 |
30.09.2019. 16.35, "Paul Clarke" <address@hidden> је написао/ла:
>
> 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.
>
Absolutely agree. I thought if the 'undefined' behavior is something obviously simple, we could try to match it, assuming also that it remains constant across all implementations. But, this behaviour is not a simple one, so, imho, let's leave 'undefined' undefined.
Thanks for a nice experiment!
Aleksandar
> PC
[Prev in Thread] | Current Thread | [Next in Thread] |